Record the language service as permanently second-language-only

[samuelduchesne]

Adds the idf-language-service capability to the parity ledger and the names it introduces to the naming register, so that the gate accepts the surface idfkit-js is about to publish.

This lands first and alone, and the sequencing is a constitutional rule rather than a preference. check-naming-register.mjs reads the .d.ts files each package's exports map points at, so the change that adds scanIdf to @idfkit/core and publishes @idfkit/language is the change that puts every new name in scope. Landing the code before this means landing it red.

The ledger entry

tier = "never", python = "absent", typescript = "complete", absence_kind = "never", no tracked item. browser-simulation is the standing precedent for a capability complete in one language, absent in the other, and carrying no corpus cases.

The reason is on the entry. The answers are computed from byte offsets into the source text, and a second implementation of that arithmetic is the drift surface the corpus is least able to police: it compares findings on (code, line, typeName) and never on a column, so two implementations could disagree about a position for a long time with no gate noticing. The editor extension needs no port either, because its existing Python server keeps serving Python source while a second server serves IDF text.

never is terminal, and that is the point. Moving off it needs a constitutional amendment rather than an edit, which is the strength at which this decision was made. A not-yet was considered and rejected: the gate requires a real tracking issue for every not-yet, and opening one for a port nobody intends in order to satisfy a gate is exactly what the file's own header warns against.

The register entries

One [[entry]] per name, python = "", kind = "excluded", mirroring the existing eppy entry. @idfkit/language is added to [register] governs, which today reads ["idfkit", "@idfkit/core", "@idfkit/weather"], or the gate would not know to hold the new package's surface against anything.

Also here, and not a name this feature introduces: column in a finding is registered as divergent. Python string indices are code points and JavaScript's are UTF-16 code units, so the two agree below the astral planes and differ above them, which in practice means an emoji in a comment. Harmless today because a column is never compared, and registered because an unregistered divergence is indistinguishable from drift.

Two deviations from the contract, both deliberate

The names list carries 25 concepts, not the 7 contracts/governance-entries.md gives. check-parity-ledger.mjs raises E-UNREGISTERED for any name a scanned package exports that no capability claims. @idfkit/core exports ten names for this feature, so eight of them would have tripped it the moment the layer landed, and no later task adds them. The contract is what is out of date here, not the file.

position was added after the fact. The contract's "position findings" concept binds to findingsIn only, and position is exported separately so a consumer holding findings from its own run can attach regions without a second parse. The naming gate caught it at 135 of 136; it is now 136 of 136.

ProsePool is registered too. @idfkit/core declares it but does not re-export it, and explainAt cannot name its prose parameter without that export.

The corpus level does not move

conformance-2026.8 stays as it is. A capability that exists in one language asserts no cross-language agreement, so there is nothing for the corpus to compare and no case is added. The two tag series are separate precisely so a naming change does not force a corpus release.

Verification

node scripts/check-naming-register.mjs  ->  exit 0, PASS: 136 of 136 public names resolve
node scripts/check-parity-ledger.mjs    ->  exit 0, PASS: the ledger and the exported capability set agree

idf-language-service does not appear in the "no statically checkable TypeScript name" list, which is what SC-014 asked to confirm: a capability with zero corpus cases does not read as an unproven claim.

Before merge, and after

This needs the CODEOWNERS review from a maintainer of the Python side.

governance-2026.11 is deliberately not pushed with this branch. The tag must be cut from main after this merges, per governance/README.md; a tag cut from a branch points at a commit that changes under a squash-merge. Two repositories already pin governance-2026.11 and their CI cannot resolve it until that tag exists on main, so the order is: merge this, cut and push the tag, then the other two PRs go green.