Let a consumer of the shared name reach the schema prose

[samuelduchesne]

Requested by idfkit-lsp, and envelop hits the same gap. Hover on a field shows its structural facts and no sentence saying what the field is for.

BuildingSurface:Detailed · view_factor_to_ground
number|string · optional · default `Autocalculate`

The sentence that belongs under that heading is the schema's own note. It exists, it ships, and describeObjectType already resolves it. What a consumer could not do is obtain the pool.

The gap, confirmed rather than taken on report

• idfkit re-exports httpSource but not nodeSource or readBundleFileSync; those live behind @idfkit/schemas/node, a package a consumer of the shared name did not install.
• idfkit/node is @idfkit/core/node, which exposes schemas() and schemaFor() and nothing for prose.
• read returns unknown and docs.json is a bundle-layout detail, so the only route was to hardcode a name and cast. Both would break silently if the layout moved.

What this adds

SchemaBundle gains loadProse() and prose() — the same pair as load(version) / loaded(version), with the same in-flight sharing.

import { schemas } from 'idfkit/node';
const bundle = schemas();
await bundle.loadProse();   // once, off the critical path
bundle.prose();             // ProsePool | undefined, synchronous

On the bundle, not a free-standing loader

This is the one decision worth arguing, and it departs from the shape the request sketched.

The indices are only meaningful against manifests built in the same run. build.mjs writes docs.json and the manifests together, and SlimType.m / SlimField.n point into that exact array. A pool paired with manifests from another build resolves every sentence to a real sentence belonging to a different field, and nothing fails.

A module-level prose singleton in idfkit/node would make that pairing easy to reach: the consumer most likely to supply its own BundleSource is the browser one, which is envelop. Putting the loader on the bundle that carries the indices makes it hard to reach by accident.

It also answers both runtimes at once, which the request asked for separately. envelop reaches schemas through httpSource today and gets the pool the same way, with nothing node-specific in the path.

The synchronous accessor

Kept, and for the reason the request gave. Every reader of prose is synchronous: describeObjectType takes a pool rather than fetching one, and every answer in @idfkit/language is a pure function, which is what lets an editor server answer a cursor without holding a thread. Load once when a document arrives, read on the request path.

What does not change

ProsePool moves from @idfkit/core to @idfkit/schemas, because schemas cannot import from core and the pool is a schemas artifact. Core re-exports it, so the name a consumer imports is unchanged and the register entry still resolves.

Nothing about the parse path moves. check:bundle-purity still reports a minimal read-and-write bundle at 18.3 KB with no schema data. describeObjectType with no pool still returns structural facts with prose: undefined, never text derived from a field name (FR-022).

Measured

Over ten common types in 26.1.0: with the pool, 10/10 carry a memo and 52/103 fields carry a note; without it, none do. The other 51 have no note in the schema itself.

Install grows 5,657 bytes, 1,795,857 to 1,801,514 against a budget of 1,835,008: 98.2 percent, 32.7 KB headroom, down from 38.2 KB. The pool was already installed; this is the loader. The budget is not moved.

Governance

idfkit-conformance#3 registers SchemaBundle.loadProse and SchemaBundle.prose as divergent, on the same footing as SchemaBundle.load against get_schema.

It does not block this PR. The naming gate's coverage reaches top-level exports, and a method on an exported class sits outside that reach — check-naming-register.mjs says so in its own header. check:naming passes here at 136 of 136 either way. Unlike feature 005, no tag is a prerequisite.

Gates

typecheck, test (703, up from 699), format:check, check:naming, check:parity, check:facade, check:bundle-purity, check:install-size, check:no-index all green locally. check:publication still refuses on the pre-existing FR-044 conformance-level question.