TypeSchema: precompute derived slice facts and refine the slicing model

[ryukzak]

Second PR of the slice-refactor sequence started in #203.

Derived slice facts

• FieldSlice gains four derived facts, computed once at snapshot build (enrichSlice in the index): effectiveRequired (required − match keys − choice-declaration base names), constrainedChoice (the single narrowed choice variant), autoStub (stub-eligible with just the discriminator match), resourceType (matched resource type of type-discriminated slices).
• TS and Python writers consume the facts instead of re-deriving them per language; the duplicated collectors (choice-base resolution, tsIndex.constrainedChoice calls, two divergent resource-type extractors) are deleted.
• Two bugs fixed by the unification:
  • validateSliceFields/validate_slice_fields no longer require choice-declaration base names — a phantom key ("value") that never exists in FHIR JSON and could only false-fail;
  • Python no longer auto-stubs slices that need user data beyond the match (adopts TS semantics); extension profiles keep extension as an optional create() param populated via sub-extension setters, mirroring the TS Raw type.
• Transform-level tests cover all four facts, including the deliberate asymmetry: choice-base names are dropped from effectiveRequired but still block autoStub.

Slicing model refinements

• match becomes a discriminated SliceMatch union: { kind: "value" | "type", value }; empty matches are no longer stored, so consumers test presence instead of key-counting.
• Extension-style slices are fully populated: the { url } match is recovered from schema.url and cardinality from the slice schema (fhirschema convention) — no more degenerate slicing entries. Writers replace the accidental skip (missing match) with an explicit ownership rule: on resource-based profiles extension/modifierExtension slices belong to the ProfileExtension mechanism; Extension-based profiles keep their sub-extension slice API.
• Re-slicing a field now refines the inherited slice set in flatProfile (leaf header and same-name slices win, inherited slices survive) instead of replacing it wholesale.
• docs/type-schema.schema.json documents the slicing model (incl. derived facts) and the reference: { resource, profiles } shape from TypeSchema/TS/PY: resolve reference targets to base resources, keep profile expectations separately #201.

Example of the enriched serialized slice (BP component):

"SystolicBP": {
  "min": 1, "max": 1,
  "match": { "kind": "value", "value": { "code": { "coding": [{ "code": "8480-6", "system": "http://loinc.org" }] } } },
  "required": ["value"],
  "constrainedChoice": { "choiceBase": "value", "variant": "valueQuantity", ... },
  "autoStub": false /* needs a valueQuantity, not just the match */
}

Generated output changes are limited to the two bug fixes (US Core race/ethnicity/tribal extension profiles, TS + Python); everything else is byte-identical.