can:// ids label JavaScript modules as typescript — split the language namespace #114

Problem

src/schema/ids.ts:11 hardcodes const LANGUAGE = "typescript" and every code id descends from it,
so a JavaScript module emits can://typescript/<app>/lib/foo.js/fn. The first can:// segment is
defined as a language namespace, so .js modules are currently labelled as TypeScript.

Measured on nodejs/node/lib — 406 modules, pure JavaScript — every id reads can://typescript/….

This also runs against the repository-artifact layer, which deliberately uses a language-NEUTRAL
namespace (can://artifact/<app>/<path>) so sibling analyzers over one repository mint identical
ids for the same file. Code nodes encode a language, and for JS it is the wrong one.

Spec: docs/design/specs/js-language-namespace.md

Scope boundary

The language segment of code ids only. Not in scope: the artifact layer (already neutral), the
:Application anchor (stays can://typescript/<app> by decision), modulePrefixOf's shared
prefix for a.ts/a.js (prevented upstream by discovery's sibling rule, unchanged here), and
prov vocabulary.

Goals

• moduleIdOf derives the namespace from the file key: .js/.jsx/.mjs/.cjs →
  javascript, .ts/.tsx/.mts/.cts/.d.ts → typescript
• The :Application id is unchanged, and the single-anchor invariant (fix: neo4j :Application node has no version (JSON/neo4j analyzer-identity divergence) #43) holds
• A fixture with both a .ts and a .js module asserts both namespaces in one run
• .d.ts is asserted explicitly — it must resolve to typescript, not be read as a .ts
  suffix on a .d file
• Neo4j projection and JSON agree; conformance and count-parity gates stay green

Caveats and known risks

• Breaking for JS ids. Neo4j MERGE keys on id, so re-projecting creates new nodes for JS
  modules instead of updating existing ones — a store built by an earlier version needs a rebuild.
  Saved Cypher and any persisted references to JS node ids must be updated.
• The application id will be inconsistent with its own children — it says typescript while
  owning javascript modules. Accepted knowingly: a neutral anchor (can://app/<app>) is the more
  coherent end state but changes every id in every projection, and two anchors would break the
  single :Application invariant. A mixed repo has no single language, so any single-anchor scheme
  names one language or none.
• The cache is unaffected — ids are stamped per run because they embed --app-name, and the
  cached tree is id-free.
• No python change: python is single-language and has no analogue. No schema_version move, by the
  standing decision that the contract re-baselines once every analyzer is stable.

Definition of done

A run over a fixture containing both languages emits can://javascript/… for the .js module and
its callables, can://typescript/… for the .ts module and its callables, an unchanged
:Application id, and green conformance/parity gates.