Reach full parity and meaningful editability for the Peaky Barbers reference import

## Problem

The public Peaky Barbers site (`https://www.peakybarbers.gr/`) compiles and materializes through packaged Static Site Importer `1.8.4` and Blocks Engine PHP Transformer `0.8.2`, but the resulting WordPress site does not meet the full-parity or meaningful-editability gates.

The import is mechanically complete: all seven routes render, all loaded blocks are valid, responsive shared headers and footers are template parts, images load, internal navigation resolves, and the job application becomes a native Jetpack form. Those signals currently coexist with concrete frontend, runtime, fallback, and authoring failures.

## Reproduction

1. Capture `https://www.peakybarbers.gr/` as a bounded multipage artifact.
2. Compile through the packaged Blocks Engine PHP Transformer.
3. Materialize the canonical WordPress site plan through packaged Static Site Importer.
4. Compare source and WordPress at desktop and mobile widths.
5. Open the homepage in the post editor and Site Editor, inspect loaded blocks, List View, console errors, and ordinary owner edits.

Observed against Transformer `0.8.2` and SSI `1.8.4`:

- seven routes return successfully and 55 visible homepage images load;
- quality fails with 18 unsupported HTML fallbacks and 28 generated `core/html` blocks;
- source header is 113 px tall and hides on scroll; WordPress header is 295 px tall and remains fixed;
- source header controls are direct hit targets, while WordPress center-point hit testing lands on an overlapping layout container;
- imported motion targets remain paused at `opacity: 0`;
- mobile output has no horizontal overflow but contains large empty geometry and mojibake in Greek address/copyright text;
- homepage editor loads 837 valid blocks at maximum depth 17, including 14 `core/html` blocks and four responsive template-part references;
- editor startup reports duplicate Jetpack data-store registrations;
- the job application has one visible and one hidden responsive Jetpack form variant, but owner submission evidence remains required.

## Ownership

This issue is the reference-site acceptance tracker, not a request for fixture-specific CSS or markup repairs.

- Blocks Engine owns source interpretation, semantic authoring, responsive structure, text decoding, motion/runtime projection, fallback reduction, and visual geometry.
- Static Site Importer owns WordPress materialization, provider readiness, editor/runtime acceptance evidence, and the final owner-handoff decision.
- Generic child issues should carry each independently repairable root cause.

## Acceptance criteria

- Packaged releases reproduce all seven routes from the public source without development loaders or checkout overrides.
- Desktop and mobile source-versus-WordPress comparison passes the configured exact visual gate with no unexplained geometry drift.
- Header dimensions, scroll behavior, visibility, direct hit targets, and route-current state match the source.
- Authored motion reaches the same visible terminal state and does not leave content paused or transparent.
- Unicode text is byte- and glyph-correct across source artifact, canonical plan, WordPress storage, frontend, and editor.
- The final site contains zero unsupported fallbacks, zero `core/html` blocks, and zero invalid blocks.
- Responsive headers and footers remain shared template parts while ordinary authoring uses one comprehensible responsive structure rather than duplicate breakpoint documents.
- Editability evidence proves normal owner tasks: edit text, replace media, edit navigation, reorder a section, edit shared footer content, configure the form recipient, save, reload, and undo/redo.
- Editor and frontend presentation remain equivalent at matched canvas widths, with no duplicate registration or runtime console errors.
- The Jetpack form passes required-field, valid submission, provider-failure, duplicate-submit, and WordPress-owned receipt checks without retaining a source endpoint.
- SSI owner-handoff evidence binds the passing visual, editor, fallback, provider, route, and materialization receipts before accepted/built status is allowed.

## Related

- #868
- #220
- #1367
- #1387
- Automattic/static-site-importer#489
- Automattic/static-site-importer#495
- Automattic/static-site-importer#673
- Automattic/static-site-importer#961
- Automattic/static-site-importer#1413
- Automattic/static-site-importer#1414

## AI assistance

OpenAI GPT-5.6 Sol via OpenCode was used to run the packaged import audit, compare browser/runtime/editor evidence with the public source, reconcile existing trackers, and draft this issue. Chris Huber directed the acceptance standard and remains responsible for the report.

Start by reproducing the seven-route import from the Peaky Barbers URL with packaged Transformer 0.8.2 and SSI 1.8.4, then inspect the stated frontend, editor, fallback, runtime, and form evidence. Use the related child issues to identify independently repairable work; done requires all listed visual, Unicode, block, editability, runtime, form, and owner-handoff acceptance gates to pass.

Written by the indexing model from the issue text.