Release v4.30.0

Code written inside a Screenplay document can now be mapped back to the exact characters it came from, so a host editor that hands a body to a language service (C#, TypeScript, SQL) can put completions, hovers and diagnostics on the right place in the .play file. Screenplay supplies the mapping data; the language service stays in the host editor, as decision 0002 says.

Added

• CodeBlockSyntax.BodyStartOffset, BodyEndOffset, BodyStart, BodyEnd and BodyLines: the body's span in the document (UTF-16 offsets, BOM-less, as editors address text) and, for each body line, the original line and the column where its content starts after the common indentation is removed. This covers fenced bodies with a language info string and the legacy tag-line form, CRLF documents, tabs, blank and under-indented lines, and bodies at the end of a file.
• SemanticImplementationRequirement.BodySpan and BodyLines (SemanticImplementationBodySpan, CodeBlockSourceLine): the same map for each implementation attachment. A file attachment whose contents were supplied spans the whole file; an unresolved file attachment and an inline body without parser positions have no span.
• The MCP implementation-requirements views (workspace and proposal) return bodySpan and bodyLines, run-length encoded where consecutive lines share a column, so a long body stays within a page.

Changed

• CodeBlockSyntax and SemanticImplementationRequirement compare body line maps by value, so two parses of the same text are equal. Positions do not take part in syntax structural equality, so moving a body inside a document never produces a workspace change on its own.

Canonical ESM bytes are unchanged; the map is tooling data, not model meaning.