span.bytes are declared as UTF-16 char offsets but the Neo4j projection slices code as UTF-8 bytes

[rahlk]

Is your feature request related to a problem? Please describe.

src/schema/schema.ts:29-31 declares TSSpan.bytes as UTF-16 character offsets into TSModule.source, and the level-3 builder produces them that way (src/schema/graphs.ts:38). The Neo4j projection derives each declaration's code property by slicing module.source with those offsets as if they were UTF-8 byte offsets (src/build/neo4j/project.ts:274-280).

The two agree on ASCII and disagree on any file containing a non-ASCII character before the declaration — the slice is shifted by the cumulative multi-byte surplus, so code on the graph starts or ends mid-token.

• A consumer that slices source by span.bytes (as declared) and one that reads code off the graph get different text for the same callable — exactly the kind of cross-backend disagreement the SDK's parity tests exist to catch, and it would show up only on a corpus with non-ASCII source (comments and string literals are enough).
• schema.neo4j.json documents code without saying which offset semantics produced it.

Describe the solution you'd like

Not stated in the original issue.

Describe alternatives you've considered

Not stated in the original issue.

Additional context

Suggestion

Pick one and make both sides use it: either keep bytes as character offsets and slice source by characters in the projection, or rename/redefine the field as byte offsets (a schema-major change) and fix the builder. The first is the smaller change. Add one fixture file with a non-ASCII comment above a declaration and assert the graph's code equals the character slice.

Definition of done

• code on :TSCallable equals module.source.slice(span.bytes[0], span.bytes[1]) (as characters) for a declaration preceded by non-ASCII text.
• The schema doc states the offset semantics once.

Found while inventorying the 1.2.0 wire schema for python-sdk leg 2.5.