TypeSchema/TS: emit validateRequired() for inherited base-required fields

[sussdorff]

Summary

• Profile snapshots silently dropped any base-resource cardinality the profile differential did not re-state. Generated `validate()` methods therefore skipped inherited required fields (e.g. `Provenance.target`, `Provenance.recorded`), so resources missing those fields passed TypeScript-side validation only to be rejected by the FHIR server at write time.
• `SnapshotProfileTypeSchema` now carries an optional `inheritedRequiredFields: string[]` listing top-level base fields the profile chain leaves untouched. `buildProfileSnapshot` populates it; the TS writer appends one `validateRequired()` call per entry.
• Why a separate list instead of merging base `fields` into the snapshot: a full merge would also pull every base choice variant (`valueString`, `valueRange`, …) into the profile's getter/setter surface — even on profiles that explicitly narrowed `value[x]` to one variant. Keeping `fields` as the differential-merged view and `inheritedRequiredFields` as the additive validation hook avoids that bloat.
• `flatProfile` merge loop also handles the relaxation case: if any profile in the chain sets `min: 0` on a field, the merged field's `required` is reset to false. Without this, the field-builder's `isRequired` walk would still return true (because the base ancestor requires it) and `validate()` would emit `validateRequired()` for a field the profile intentionally relaxed.

Generated code (Provenance profile that does NOT re-state target/recorded)

Before:
```typescript
validate(): { errors: string[]; warnings: string[] } {
const profileName = "PraxisProposalProvenance"
return {
errors: [
...validateRequired(res, profileName, "activity"),
...validateRequired(res, profileName, "agent"),
],
warnings: [],
}
}
```

After:
```typescript
validate(): { errors: string[]; warnings: string[] } {
const profileName = "PraxisProposalProvenance"
return {
errors: [
...validateRequired(res, profileName, "activity"),
...validateRequired(res, profileName, "agent"),
...validateRequired(res, profileName, "target"),
...validateRequired(res, profileName, "recorded"),
],
warnings: [],
}
}
```

Tests

• Unit (`test/unit/typeschema/utils.test.ts`): three cases covering inherited-required collection, `min: 0` relaxation, and the all-restated path that yields `undefined`.
• Snapshot (`local-package.test.ts.snap`): `ExampleTypedBundle` regenerated — `Bundle.type` is base-R4 required and was previously missed.
• Existing R4 and US Core example snapshots are unchanged (those profiles already restate every base-required field).

[ryukzak]

Follow-ups now that this is merged:

• TS: generate per-type validate() functions and have profile validators delegate to them #169 — issue tracking the broader redesign: generate per-type validate<Type>() free functions and have profile validators delegate to them. This subsumes inheritedRequiredFields (the side-list added here), the inherited-required emit loop, and the base-level min:0 reset — and closes the inherited choice/reference/binding gaps uniformly via the shared emitter.
• TypeSchema: skip base choice declarations in inheritedRequiredFields #170 — small guard on top of this PR: skip base choice declarations (e.g. value[x]) in the inheritedRequiredFields collection, so validate() never emits validateRequired("value[x]") (a check against a key that never exists in FHIR JSON). Proper validateChoiceRequired() handling is deferred to TS: generate per-type validate() functions and have profile validators delegate to them #169.
• TS: example demo for inherited base-required field validation #171 — behaviour-level example test: runs the generated ExampleTypedBundle profile and asserts validate() flags a missing inherited Bundle.type. Complements this PR's text/snapshot assertions by exercising the generated code at runtime, and survives the TS: generate per-type validate() functions and have profile validators delegate to them #169 redesign.

[sussdorff]

Thank you! highly appreciated. So far it did not find any issues with the new code generation on our end, so this looks good to us.