TypeSchema/TS: drop isWithMetaField; inline isResourceIdentifier(base)

[ryukzak]

In FHIR only resources carry meta, so the hierarchy walk in isWithMetaField is equivalent to isResourceIdentifier(flatProfile.base). Inlining the check removes a redundant index helper and simplifies a couple of writer conditions.

Changes

• Remove isWithMetaField from TypeSchemaIndex (interface, implementation, return-object key).
• Inline isResourceIdentifier(flatProfile.base) at both call sites in src/api/writer-generator/typescript/profile.ts.
• Simplify canEmitIs from (hasMeta && isResourceIdentifier(base)) || base.name === "Extension" to hasMeta || base.name === "Extension", and the nested branch from hasMeta && isResourceIdentifier(base) to just hasMeta.
• Drop now-unused tsIndex params from generateProfileHelpersImport and generateFactoryMethods.
• Remove the stale entry from docs/guides/typeschema-index.md.

Verification

• bun run typecheck clean
• bunx biome check clean (only pre-existing warnings)
• bun test 257/257 pass
• R4 and US Core examples regenerate byte-identical

[ryukzak]

Closing — the simplification is unsound.

CI surfaced the issue: isWithMetaField and isResourceIdentifier(base) are equivalent for FHIR R4/R5 but diverge for CDA logical models promoted to resources. CDA's Section, SubstanceAdministration, Supply, etc. get kind: "resource" via promoteLogical but extend InfrastructureRoot, not FHIR's Resource — so they have no meta field.

After inlining, the writer emits resource.meta?.profile?.includes(...) for those CDA profiles, which fails to typecheck:

Section_ProblemSection.ts(57,23): error TS2339: Property 'meta' does not exist on type 'Section<object>'.
Section_ProblemSection.ts(74,23): error TS2559: Type 'Section<object>' has no properties in common with type '{ meta?: { profile?: string[] | undefined; } | undefined; }'.
Section_ProblemSection.ts(94,13): error TS2353: Object literal may only specify known properties, and 'meta' does not exist in type 'Section<object>'.

The hierarchy walk in isWithMetaField is doing real, FHIR-specific work: it answers "does the base have a meta slot anywhere in its ancestry?" — which is a property of the hierarchy, not of identifier.kind. The helper is required.

The right home for this concept is on the future snapshot facts (precomputed hasMeta: boolean), where it goes away as a method because it becomes data on the snapshot. Until then, keep the helper.