Interface NamespaceMapping

Map bim.<namespace>.<method> call sites to capability requirements.

The static analyzer (see ./capability.ts) walks the AST of a saved script, collects every bim.<ns>.<method> invocation, and joins each one to this table to produce the minimum capability set the script needs at runtime.

The table is conservative: when a method's intent is ambiguous (e.g. bim.export.* could produce any format), we map to a broad capability with a wildcard target that the user can narrow on the review screen.

Adding a new entry here is the only place where a new bim.<ns>.<method> becomes "known" to inference. Unknown calls surface as the fallback model.read plus a warning in the inference result so the user/AI can investigate.

Two shapes of namespace entry, and they warn differently on a miss:

• FLAT (no methods map): every real method in the namespace is documented to share defaultCapabilities (e.g. query, create). A method not listed here still resolves to that default, silently — that is the intended behavior, not a gap.
• DIFFERENTIATED (has a methods map): capability varies by method here, so the map is the namespace's complete classification set, not a list of exceptions. Every real bridge method gets an entry, including the ones whose answer is the namespace default (see model.list, export.download) — writing the default out is how the table records "this method was looked at". A method absent from a complete map is therefore one nobody classified: it still resolves to defaultCapabilities (never under-grant), but isRecognisedMethod reports it as unrecognised so capability.ts can warn.

Keep this in sync with @ifc-lite/sandbox/schema (NAMESPACE_SCHEMAS). Nothing machine-checks that sync, so a differentiated namespace's map can fall behind a newly added bridge method. It falls behind in the safe direction: the new method warns until someone classifies it.