Authoring: accept equivalent image dimension representations

[noeltock]

Problem

A proposal that repeats an image's authored width as numeric 960 is rejected when the source contains width="960". The visible value is unchanged, but bindContent compares JSON representations and classifies it as an unreviewed content change.

Core already derives these attributes. Callers should normally omit them, but equivalent native numeric input should not consume a repair attempt or require a fabricated design-change decision.

Reproduction and cause

Reviewed at PR #69 commit 9680c5cc66bf17a3f803cf2eff4ddd75d41bdbf5.

1. Analyse a local source containing <img src="./image.svg" alt="Example" width="960" height="640"> with collectSourceEvidence() and a valid local asset.
2. Bind that image (or its figure) to core/image in an otherwise supported proposal.
3. Compare the omitted-dimension case with attributes: { width: 960, height: 640 }.

sourceAttributes returns positive-integer HTML dimensions as strings. bindContent compares JSON.stringify(attributes[attribute]) with JSON.stringify(value), so 960 and "960" differ. The observed rejection was:

proposal product-image.width changes source content without an explicit source decision

Read src/author/proposal.ts bindContent and sourceAttributes. Reuse test/author.proposal.test.ts and its source/asset helpers. No model or WordPress process is needed to reproduce this comparison.

Minimal correction

source width="960" + proposed width=960
  → equivalent source fact
  → existing source-derived canonical value

source width="960" + proposed width=961
  → explicit source-change decision still required

Make equivalence narrow and field-specific: only supported positive safe-integer core/image width/height values that denote the same authored dimension. Keep the existing source-derived canonical representation so omitted, string-equivalent and numeric-equivalent proposals converge on the same output. Avoid general JSON coercion, CSS-unit conversion or changing canonical-plan validation.

Use the existing execution/audit alias mapping as the source of truth. Actual replacements still follow explicit source-decision handling; do not introduce a second set of dimension rules in the audit path.

Acceptance criteria

• Direct-image and figure-bound proposals accept equivalent numeric/source-string dimensions and produce the same canonical result as omitted dimensions.
• A different width/height still fails without an explicit source decision; a valid authorised change retains its existing audit behaviour.
• Fractions, zero, negative values, non-finite numbers, booleans, objects, unsafe integers and CSS units are not admitted through the equivalence shortcut. Existing validation remains authoritative.
• Equality handling for text, URLs, alt text, captions and other attributes is unchanged.
• Source hashes, content-preservation checks, backward-compatible complete-plan input and tamper rejection remain intact.
• One focused regression covers the observed numeric/string case, with a small negative matrix for actual changes and invalid representations.

Scope and ordering

This is a narrow follow-up to #62, not a redesign of the proposal boundary. Keep it out of #65's instruction-only comparison until that frozen attempt is recorded; changing compiler behaviour during the comparison destroys its ability to distinguish instruction problems from implementation problems. It can then be integrated as an independently tested correction.

Own src/author/proposal.ts and test/author.proposal.test.ts unless tracing the current caller reveals a necessary additional boundary. Run npm test -- test/author.proposal.test.ts and npm run typecheck, followed by required integration checks on the stable candidate. No model run, new normalisation framework, native-structure substitution or publication.