JSTypedArray: annotate swjs_create_typed_array for bounds-safety

[airspeedswift]

On recent clang/Swift toolchains, bounds-safety annotations on void * parameters cause the Swift importer to synthesize an UnsafeRawBufferPointer-taking overload alongside the original. Adding these annotations to swjs_create_typed_array gives us that overload for free, and it lays the foundation for broader Span adoption in JavaScriptKit in follow-up PRs.

Because elements_ptr is void *, the byte count is length * sizeof(element). This PR adds a trailing element_size parameter and annotates elements_ptr as __sized_by_or_null(length * element_size) __noescape. Both annotations are correct given the JS implementation: it constructs a typed array view over WASM linear memory at elementsPtr with length elements and immediately calls .slice() to copy before returning. The view constructor reads exactly length * constructor.BYTES_PER_ELEMENT bytes, which equals length * element_size since Swift passes MemoryLayout<Element>.stride — matching BYTES_PER_ELEMENT for every TypedArrayElement type. And because only the .slice() copy is retained and returned, elementsPtr never escapes the call. __sized_by_or_null rather than __sized_by preserves the existing nullable contract: Swift's Array.baseAddress is nil for empty arrays, and the JS side already handles length == 0 without dereferencing the pointer.

The only coordinated change is in JSTypedArray.swift's createTypedArray, which passes Int32(MemoryLayout<Element>.stride) as the new argument; the JS dispatch entry is unchanged — extra WASM arguments are silently dropped.

The alternative is to redefine length as a byte count and drop element_size, collapsing the bounds expression to
__sized_by_or_null(byte_length); – this is a narrower change that doesn't update the typescript, but you could argue the alternative is cleaner.

[airspeedswift]

removed the guard checking for clang headers, that's probably overkill if you assume the minimum tools version, but can put it back if this repo's practice prefers it.

[airspeedswift]

hmm guess I was wrong about ptrcheck being quite so available...

[airspeedswift]

Moving this to draft pending decision about how best to handle 6.1 toolchain support. Also needs some tests for calling the safe version.

[krodak]

@airspeedswift this should be safe to rebase now.

The red checks here are from the old CI matrix. The failures were just the bounds-safety headers not shipping in the 6.1/6.2 clang - fatal error: 'ptrcheck.h' file not found on Swift 6.1 and 'lifetimebound.h' file not found on Xcode 16.4. The jobs that don't compile the C header (the BridgeJS-only ones) passed. main has since dropped 6.1/6.2, so a rebase should clear those.

One thing to pair with the rebase: Package.swift still declares swift-tools-version:6.2, so a 6.2 toolchain would hit the same missing-header error. Bumping it to 6.3 lines the manifest up with the dropped versions and these annotations. (The alternative is guarding the includes with __has_include, but with 6.2 gone the tools-version bump is the cleaner option.)