No unknown-extension lint: a stray x-overslash-* or a misplaced key compiles to a silent no-op

[angel-manuel]

Why

Found while shipping D57. services/metabase.yaml carried response_type: binary on export_query for months. It did nothing.

response_type is not in OPERATION_ALIASES (crates/overslash-core/src/openapi/alias.rs), and extract_http_action only ever derives a response type from a responses: block via detect_response_type — it never reads the key off an operation. metabase.yaml declared no responses:, so export_query.response_type compiled to None, the "use prefer_stream" hint documented on ServiceAction never fired, and a large xlsx export was buffered against max_response_body_bytes instead. D57 fixed that one instance by writing a real responses: block.

Nothing caught it, and nothing would catch the next one. A stray x-overslash-foo, a typo'd x-overslash-disclsoe, or a valid key in a position nothing reads is silently ignored at compile time. D55's rationale records the same failure mode from a different angle: a resolve: block sat next to an already-unprefixed risk: in services/whatsapp.yaml and did nothing, and the only symptom was an approval still quoting a raw ID.

Suggested direction

Lint unknown x-overslash-* keys, and known keys in positions that are never read, at template compile — reported through template_validation::validate_service_definition so it reaches both the shipped-template test and the user/org template authoring path.

Two things to get right:

• Position matters, not just spelling. response_type: was a real concept in the wrong place. The lint has to know where each extension is read from, not merely that the name exists somewhere.
• Expect an initial sweep. This was deliberately kept out of the D57 PR because turning it on will surface unrelated findings across every shipped template at once, and mixing that into a feature PR would bury both. Land the lint and the sweep together, on their own.

Note the failure mode this guards: registry.rs logs and skips a template that fails to load, rather than failing hard. shipped_services_have_no_silent_skips is the test that keeps a skip from hiding — an unknown-extension lint is the same idea one level down, for a template that loads fine and just quietly does less than it says.

[angel-manuel]

Implemented in #554 (D67 — renumbered from D66, which dev took for the gated-async work in #553).

Two findings worth recording on the issue itself:

The predicted sweep was empty in services/. A strict closed-world scan across every structural position of all 23 shipped templates found zero findings, and shipped_services_lint_clean passed on its first run. response_type survives only as an explanatory YAML comment in metabase.yaml. The real offenders were elsewhere — most importantly the dashboard's own new-template scaffold, which seeded x-overslash-prefix (removed by D35, rejected outright by extract_api_key), so the default skeleton could not be saved at all.

Neither motivating bug is an x-overslash-* key. response_type is a ServiceAction field name and D55's resolve: is an alias, so the lint the issue describes — unknown prefixed names plus known names in the wrong place — would have caught neither on its own. The load-bearing rule turned out to be a fourth one: an unrecognized bare key at a position whose fields we enumerate. That is what catches response_type: binary on an operation.

One deliberate deviation: findings are reported from template_validation's three YAML entry points rather than from validate_service_definition itself, which takes the compiled ServiceDefinition where extension keys no longer exist — the same wrapper layer that already owns check_duplicate_operation_ids for the same reason. Both consumers named in the issue are reached.