Keep truncated form layout graphs fallback-only

## Problem

Blocks Engine already keeps forms with truncated `control_topology` out of `generic/forms/v1` runtime declarations, but it still publishes forms whose `layout_graph.truncated` is `true`. Static Site Importer correctly rejects those incomplete provider-bound declarations.

This blocks the Shopify evidence workload tracked by Automattic/static-site-importer#768. The current artifact produces 12 forms rejected at `$.forms[0..11].layout_graph` with `layout_graph is truncated.`

## Expected behavior

A form with either truncated control topology or a truncated computed layout graph remains an explicit `html_form_fallback` finding and static fallback, without claiming provider materialization through a form entity collection or dependency. Complete forms continue to emit the existing `generic/forms/v1` contract unchanged.

## Acceptance criteria

- Truncated layout graphs remain present in fallback diagnostics.
- Forms with truncated layout graphs are omitted from provider-bound runtime declarations.
- Complete form declarations remain byte-compatible.
- Contract coverage proves both behaviors.

## AI assistance

GPT-5.6-sol via OpenCode identified the producer/consumer contract mismatch from WP Codebox runtime evidence and helped draft this issue. Chris Huber remains responsible for the report and resulting changes.

Trace the producer and consumer of layout_graph.truncated, including the generic/forms/v1 runtime declarations and html_form_fallback diagnostics. Start by locating the existing contract coverage for truncated control_topology, then verify that truncated layout graphs remain in fallback diagnostics, are omitted from provider-bound declarations, and leave complete declarations byte-compatible.

Written by the indexing model from the issue text.