[Tracking] Features derived from existing compiler/runtime metadata

[cssbruno]

Tracking issue. A codebase audit (compiler IR plus runtime/addons) found that the highest-leverage next features share one shape: metadata GOWDK already computes, gaining a new consumer. None of these touch the parser or change language semantics, except #177, which is a deliberate small lift.

• feat: diagnostics registry severity + machine-readable fixes (gowdk fix, LSP code actions, overlay) #178 diagnostics severity + fixes (registry powers gowdk fix, LSP code actions, overlay) - M2
• feat: render page metadata (OG/Twitter tags, canonical) into generated HTML #175 render page metadata into HTML - M2
• feat(addon): seo — sitemap.xml and robots.txt emission from route manifest #176 addons/seo: sitemap + robots from route manifest - M9
• feat: client-side form validation generated from action InputFields #174 client-side form validation from InputFields - M8
• feat: dynamic fragment routes (typed route params on fragment endpoints) #177 dynamic fragment routes - M7
• feat: IR-driven test harness (testkit): generated httptest endpoint tests + contract registry doubles #179 IR-driven testkit - M10
• feat(contracts): idempotency keys for at-least-once event delivery (broker/outbox dedup) #180 idempotency keys for event delivery - M6
• feat(cli): gowdk build --docker emits a Dockerfile next to the one-binary build #181 gowdk build --docker - M9

Suggested order: #178 first (makes #109 and the VS Code issues richer), then #175/#176, #174 alongside #165, #177 before the M14 reactivity work needs it, #179 coordinated with #166, #180/#181 anytime.

Not pursued now, on purpose: cron/job scheduler adapter (#114 deferral), client-language type system (wait for #97-#101 to settle the surface), LSP rename (VS Code work #103-#107 first).

Related: #170 (adapters), #165/#148 (spec exports), #147 (reactivity design input to #130).