deck: block-by-block table + component heat map from migrate's component-map.json

[JonasJesus42]

Part of #288.

The two most useful pages of a client-facing deck are the ones the CLI cannot generate yet:

1. Block-by-block before/after — one row per legacy block, its target component, a status, and
   a one-line note.
2. Component heat map — the same blocks grouped by page region (top/nav, buy box, below the
   fold, shelves), tone-coded, with a per-zone score.

The heat map is what people actually read. The table is for whoever wants the detail.

The data mostly exists

parity migrate already writes component-map.json and, for VTEX, manifest.json with
vtex.map: Array<{ vtex, faststore, confidence, count }>. That is the before/after mapping. What
is missing:

• Status. The mapping says what corresponds to what, not whether the target actually reaches
  parity. Four states are needed: parity, divergent, missing, shipped-this-round. Only the first
  three could be inferred (from visual diff + presence in the candidate DOM); the fourth is
  inherently a human statement about the current round.
• Page region. component-map.json has no notion of "buy box" vs "below the fold". This could
  come from vertical position in the capture, which is cheap and roughly right, or from a small
  hand-maintained region map per page kind, which is accurate and drifts.
• The note column. Judgment. Should stay hand-written; the generator should leave it empty
  rather than inventing it.

Suggested split

Generate the skeleton — rows, target components, inferred status, zone grouping — and leave status
overrides and notes to a sidecar the human edits, in the same spirit as migration-plan.json.
A generated table nobody trusts is worse than a hand-written one.

Open question

Whether this belongs to migrate (it owns the mapping) or to the deck renderer (it owns the
presentation). Leaning toward migrate emitting a blocks array in DeckModel shape, so the
renderer stays dumb.

[JonasJesus42]

Partly unblocked by #294 (merged): the two things this issue listed as missing now exist, though in migration-plan.json rather than component-map.json.

• Status — was "the mapping says what corresponds to what, not whether the target reaches parity". PlanComponent.status now covers it with the four states this issue asked for: pending/partial (build), done, as-is, upgrade. The fourth one this issue called "inherently a human statement" is exactly that — only the user sets it.
• Page grouping — was "component-map.json has no notion of buy box vs below the fold". PlanPage.components[] now carries page membership straight from the capture, so grouping by page is available without inferring from vertical position or hand-maintaining a region map. Zone grouping within a page is still open.
• The note column — still judgment, still hand-written, as this issue argued. reference.note is the one place a written reason is now required, and only for as-is/upgrade.

So the open question shifts: the deck's block table and heat map should probably read the plan, not the component map, since that is where status and page membership live. The migrate vs renderer ownership question in this issue resolves the same way — migrate already owns the plan.

Caveat carried over from #294: global components (header, footer, nav) are not page members in the capture, so a page-grouped heat map will not show them. They need a zone of their own, keyed on scope: global.