TS: demonstrate fixed[x] merge corner case (WIP)

[ryukzak]

Draft — adds a failing-by-design demonstration of the fixed[x] vs pattern[x] issue from #165. Test only; the codegen fix is not included yet.

Context

#165 made generated profile apply() merge fixed values (applyFixedValue) instead of overwriting them. That is correct for pattern[x] and slice discriminators, but a true FHIR fixed[x] requires the element to be exactly equal to the fixed value. The generator does not branch on valueConstraint.kind, so fixed[x] is merged too — and validateFixedValue uses containment (matchesValue), so it accepts the merged result.

What this PR adds

• New PatientFixedMaritalStatus StructureDefinition — a true fixedCodeableConcept on Patient.maritalStatus (not a coding slice), registered in the example tree-shake config.
• examples/local-package-folder/profile-fixed-marital-status.test.ts — runtime tests against the generated profile class:
  • create() materializes exactly the fixed CodeableConcept.
  • apply() on a resource that already carries a conflicting coding (same system, different code) + free text merges rather than replacing — caller data survives and the fixed coding is appended — yet validate().errors is empty.

The generated apply() confirms a real fixed[x] reaches the merge path:

applyFixedValue(resource, "maritalStatus", {"coding":[{"system":".../v3-MaritalStatus","code":"M"}]});

TODO before un-drafting

• Decide and implement the fix: branch generation on valueConstraint.kind ("fixed" → exact replace, "pattern" → merge), and relabel the synthesized fixed-coding-slice constraint (field-builder.ts) as pattern.
• Update these assertions to the corrected (exact-replace) behavior once the fix lands.