feat(validator): warn when a known extension sits outside its declared context

[angela-helios]

Closes #615. The gap surfaced in Steve and Angela's extension-authoring session: the picker constrains placement, $validate never did.

What it does

The walk checks each extension/modifierExtension item whose url resolves to a registry schema with declared contexts against the index-free parent element path (Patient, Patient.name), and reports a warning-severity ExtensionContext issue on mismatch. Element-type contexts name one exact spot — Patient is the resource root, not "anywhere in Patient".

Deliberately conservative

Judged only when every declared context reads as a resource-rooted element path. Datatype-named contexts (HumanName), the Element/Resource/DomainResource catch-alls, and FHIRPath expressions make the extension unjudgeable here (the parent's type is not in hand during the walk) and pass silently — as do unknown urls and relative sub-extension urls. No false positives by construction; the common miss (a Patient extension pasted into an Observation) is caught.

Severity plumbing

• Warnings map to warning-severity OperationOutcome issues at $validate (existing rest/validation.rs mapping) and never trip enforce mode (which rejects on error-severity only).
• The Guided editor's issue count blocks saving, so it now retains only error-severity issues — context guidance belongs to $validate, not between the user and the save button.

Tests

• extension_context_mismatch_warns: birthPlace at the Patient root → silent; on an Observation → exactly one warning at Observation.extension.0; unknown url → silent. Runs against the real R4 core registry.
• Full cargo test -p helios-fhir-validator (conformance fixtures included) and -p helios-ui green; clippy clean.

[angela-helios]

The spec-examples sweep rejected the always-on design, and it was right to — updating the PR's claims:

1. Element-level judging is unsound without SD-path mapping. An instance path Questionnaire.item.item never equals the declared context Questionnaire.item; matching needs the StructureDefinition path (recursion collapsed via contentReference), which the walk does not have. Hundreds of false positives across the questionnaire examples.
2. Even root-only judging flags canonical HL7 content wholesale. The publisher places structuredefinition-wg/-fmm/-standards-status/-normative-version (declared context: StructureDefinition) on CodeSystem/ValueSet roots throughout the published spec — e.g. every codesystem-*.json example.

So the check landed as: resource-root extensions only, behind ValidationOptions::check_extension_context, default off. A profile author can opt in; a default $validate is unchanged, and the sweep pins that (all three baselines intact with the option off, and the option-on path is unit-tested). Wiring the option to something reachable — an HFS_VALIDATION_* knob or a $validate parameter — can ride a follow-up if we want it exposed.

Also for the record: an earlier push accidentally committed the re-downloaded R6 example corpus (1,375 files of line-ending churn from crates/fhir/build.rs); it was force-replaced with the clean history before review.

[codecov]

Codecov Report

❌ Patch coverage is 92.04545% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/fhir-validator/src/engine/walk.rs	92.75%	5 Missing ⚠️
crates/fhir-validator/src/engine/path.rs	90.90%	1 Missing ⚠️
crates/rest/src/validation.rs	50.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!