Authoring: return actionable source-located decisions for unresolved mappings

[noeltock]

Problem

Supplied authoring plan does not retain the complete source declaration and asset coverage. identifies a failed invariant but gives a harness no useful correction target. Exact warning text is also currently capable of becoming part of the caller's validation burden. Repeating a rejected submission cannot resolve either problem.

Once #62 moves mechanical reconciliation into Block Runner, the remaining output should tell any harness which actual design decision is needed. This is a product/API contract, not a longer prompt or a provider-specific retry loop.

Proposed result shape

resolved → canonical plan + warnings/decisions for preview
unresolved → stable diagnostic code + source reference/location
             + affected target/property + observed/required values
             + supported next action or explicit unsupported reason

This is a shape sketch, not a second response API. Extend existing BlockRunnerReport/ReportItem conventions additively and preserve their text rendering.

Technical approach

• Reuse source paths/selectors/offsets already collected by analysis. Connect diagnostics to the input-scoped references from Authoring: let Block Runner own source binding and bookkeeping #62 and to affected native node/field IDs where available.
• Replace the generic coverage-equality failure with deterministic, bounded differences: missing declarations, contradictory ownership, changed values/conditions, unmatched emitted selectors and missing asset uses. Identify the specific entry instead of dumping the entire source ledger.
• Separate mechanically resolvable state, caller decisions, unsafe/unsupported input and infrastructure failures. Do not ask the model to repair internal metadata that Block Runner owns.
• Supply structured values for safe corrections when supported. For example: which source element needs mapping, which native target cannot retain a selector, or which asset decision is missing. Never suggest deleting content, clearing coverage, disabling a gate or substituting raw HTML to make validation pass.
• Exact mandatory warning strings are core output. If containment or another policy needs consent, expose the policy decision and its effect; do not require the model to reconstruct prose.
• Keep output ordering and identifiers stable for identical inputs. Limit large diagnostic sets with an explicit total/truncation indicator, without hiding safety failures. Human-readable CLI text and structured output must communicate the same failure.
• Preserve author() as an inspect/compile operation: reporting an unresolved decision must not write files, fetch remote assets, invoke a model or alter WordPress.

Starting points

src/author/index.ts currently compares complete coverage and emits the generic supplied-plan rejection. src/author/plan.ts checks declaration fulfilment. src/types.ts carries source locations and ReportItem diagnostics. Extend these existing contracts; coordinate any shared helper changes with #62 rather than building competing reconciliation logic.

Acceptance criteria

• The observed native-versus-scoped-CSS failure either resolves deterministically through Authoring: let Block Runner own source binding and bookkeeping #62 or identifies the exact unresolved entries and source/native targets.
• Tests cover stale source references, unmatched selectors, missing asset uses and unsupported mappings with stable machine-readable codes and source locations.
• Identical rejected input gives identical diagnostics; a supported correction changes or resolves the relevant diagnostic.
• Text/JSON consumers and existing report readers remain compatible.
• No diagnostic instructs a harness to manufacture hashes, copy an internal ledger, paraphrase a required warning or bypass content/coverage checks.
• Runtime/environment failures are distinguishable from invalid model decisions and do not prompt the model to rewrite a valid design.

Depends on the ownership contract in #62; consume unresolved adapter cases from #63. A small set of direct API tests is sufficient for this issue. No paid model run or new orchestration layer is required.