Decide canonical ownership and versioning of dynamic string registries

[metaphorics]

Question

Five registry families match on bare strings at runtime with no single owner or explicit versioning policy:

1. Compiler API method strings — crates/bamts-cli/src/api_server/session.rs:159-199 matches initialize, shutdown, ten service/* methods, fourteen ast/* methods, and three compiler/* methods. npm bamti mirrors these in internal/session.js / internal/transport.js and unstable/* wrappers; the exported Transport.request(method, …) lets any caller invoke any string.
2. LSP method/lifecycle strings — lsp.rs dispatch with Content-Length JSON-RPC framing, 16 MiB message cap, UTF-16 positions (research snapshot: crates/bamts-cli/src/lsp.rs:80,622-733,1264-1313). Editor consumers outside the repo are unaccounted.
3. Native helper symbols — 53 #[no_mangle] helpers in crates/bamts-native/src/native_bridge.rs (the table already moved once from lib.rs:52-463 in the research snapshot), duplicated by bamts-codegen::Helper indices/symbol names. Generated code, the JIT binder, static archives, and the AOT linker match by string; native ABI version 1 is a separate axis.
4. External module and export names — crates/bamts-runtime/src/external_modules.rs:24-56 installs node:util (parseArgs) and node:crypto (createHash; internals hash.update, hash.digest); script_compiler gates extra installs at :58-59.
5. Env-var and selector names — BAMTS_AOT_ENTRYPOINT / BAMTS_AOT_LAUNCH_TOKEN (crates/bamts-node/src/lib.rs:22,28), BAMTS_NODE_STATICLIB / BAMTS_HOST_TARGET / BAMTS_BUILD_TARGET (crates/bamts-cli/build.rs:55-59 → crates/bamts-cli/src/driver.rs:69-71), BAMTS_CACHE_DIR (driver.rs:2781), DEP_BAMTS_NODE_RLIB (Cargo links-key, build.rs:25,53), and npm package selectors in CLI_TARGETS / NATIVE_TARGETS (npm/bamti-cli/index.js:21-31, npm/bamti/native-loader.js:19-67).

The decision to make is: per family, choose the canonical owner (which crate/module holds the constants), whether the family is a versioned external surface or an internal name, and the exhaustive-comparison mechanism that must pass before any cutover. This ticket does not choose the npm target/release table authority itself — that is the sibling npm artifact distribution boundary ticket under #156 — it treats those package names as one of the string-selectable consumers that must be enumerated.

Consumer evidence required

• Exhaustive string inventory per family from both sides of every crossing: Rust dispatch ↔ npm session/transport/wrappers; native table ↔ codegen emission + generated archives + linker; runtime registry ↔ scripts importing the specifiers; env names ↔ launcher / AOT entry / Cargo links protocol / operators.
• Wire-version evidence for method names: answer .outline/research/workspace-boundaries.md unresolved question 7 — are method names versioned independently from cliProtocol? Answer from consumer data, not naming.
• External consumer accounting: direct bamts-* Rust module consumers (.outline/research/workspace-boundaries.md question 5), editor LSP method subsets (question 12), and out-of-repo release automation (question 13); where unreachable, record unreachability and the resulting bound on the decision.
• Target/package selector strings feed from the npm artifact-distribution ticket under Rebuild and purge the complete TypeScript platform #156; here they are enumerated, not authored.

Unresolved boundary channels

• The moving tree: the helper table already changed files during the rebuild (lib.rs → native_bridge.rs). Any owner decision must include a mechanical re-runnable check, not a one-shot list.
• In-flight platform rebuild may add env names or external modules (e.g., intl provider work). The comparison gate must be repeatable, not a snapshot.
• N-API addon surface JS names (run, releaseMetadata) in crates/bamts-napi/src/lib.rs and their mapping through npm/bamti/native-loader.js:237-259,279-328 (research snapshot).

No-go conditions

• No rename, removal, or dedup of any string in any family until the exhaustive comparison across Rust, generated code, JS loaders, npm manifests, workflows, and addon metadata passes on both sides.
• The bamts-codegen / bamts-native helper-table duplication is an explicit decision family (.outline/research/workspace-boundaries.md duplicate-owners section); do not collapse it as a side effect of registry cleanup.
• Local static search never proves external absence; no family may be classified interior on repository-only evidence.

Observable acceptance

• Per family: a mechanically produced inventory (repeatable command named in the decision) of every live string constant with owner, both-side consumers (file:line), and its version axis.
• Written ownership decision per family: owning module, external-vs-internal classification, and versioning rule (which axis bumps and what bumps with it).
• Fail-closed comparison gate demonstrated on one seeded mismatch per family (e.g., generated helper name vs native table entry) — it fails, not warns.
• Explicit statement of unresolved external consumers and how the decision is bounded by them.

Blocked by

• #159: Map crate dependencies and boundary consumers — produced the dispatch, symbol, env, and package-selector evidence.
• #168: Decide the published product facade — determines which method names, wrapper surfaces, and module boundaries remain permanent.
• #169: Design the crate topology and stable facade — determines which crate owns the helper tables and other cross-cutting registries.
• #178: Define release admission lifecycle — supplies the ABI facts and launch/admission rules the env-var and method-name registries must not contradict.

[metaphorics]

Dependencies

This issue is blocked by:

• Map crate dependencies and boundary consumers #159 — Map crate dependencies and boundary consumers (produced the dispatch, symbol, env, and package-selector evidence)
• Decide the published product facade #168 — Decide the published product facade (determines which method names, wrapper surfaces, and module boundaries remain permanent)
• Design the crate topology and stable facade #169 — Design the crate topology and stable facade (determines which crate owns the helper tables and other cross-cutting registries)
• Define release admission lifecycle #178 — Define release admission lifecycle (supplies the ABI facts and launch/admission rules the env-var and method-name registries must not contradict)

Parent: #156. Feeds: #185.