[Tracking] Feature parity: rebuild interactive behaviors with WP-native primitives (not raw JS carry)

## North star
Turn a static HTML site into a **working** WordPress site with full visual AND feature parity.

## Why not just carry the JS
The transform rewrites the DOM (e.g. `.nav-toggle` → `core/button`, `#mobile-nav` drawer deduped), so the original `main.js` (which targets those selectors) would break even if enqueued. Feature parity must come from **rebuilding behavior with WP-native primitives**, pattern by pattern.

## Workstreams
- [ ] **Nav hamburger** → use `core/navigation`'s built-in responsive overlay; drop the redundant dead toggle. *(PR in flight)*
- [ ] **Forms** → convert `` to a working form block / wire a submission handler, instead of `html_form_fallback` preserved-but-dead markup.
- [ ] **Generic custom JS behaviors** → rebuild via the Interactivity API where a native block doesn't exist.
- [ ] **Measurement** (prereqs, separate issues): tighten acceptability of dead runtime islands; diagnose dropped-script and converted-control behavior loss; extend the visual-parity engine.

This is the umbrella; concrete slices ship as their own PRs.

This is an umbrella issue rather than a standalone task; start with one of its concrete child slices. For navigation, inspect the transformed core/navigation markup and the referenced main.js selectors; for forms, inspect html_form_fallback. Done means one behavior has parity through a WordPress-native primitive and ships in its own PR.

Written by the indexing model from the issue text.