fix(data-integrity): validate public inline image byte limits

[seonghobae]

Current authoritative state

This public inline-image byte-limit defect is repaired on the existing canonical single-writer Draft PR #166 / branch fix/inline-image-size-preflight-20260811. Protected shipped truth remains exact main@3b38ead2d00f44eb578d0689087b9293b3dabe1e; current exact Draft head is f0e1a2e641d5372b4e333361ee015593caeb7cc9.

The original issue snapshot named predecessor edcaf2e6afa013990b7e7bc8ce96eb9a32b41520 and correctly identified that the public validateInlineImageSource(source, maxSizeBytes) boundary interpreted only maxSizeBytes > 0, allowing invalid JavaScript numbers to disable or distort the intended byte policy. That proposition is historical RCA, not current active-PR behavior.

Current production validates the public ceiling before source-size comparison with assertValidInlineImageByteLimit(): only non-negative safe integers are accepted; 0 retains the documented size-limit-disable meaning; positive safe integers remain exact decoded-byte ceilings. NaN, negatives, fractional numbers, infinities, and unsafe integers fail closed with one stable payload-redacted RangeError without coercion, rounding, clamping, normalization, inference, or reflection of the supplied value.

The same canonical lane preserves strict raster data-URI grammar, malformed-source error precedence, decoded-size derivation without base64 allocation, and Base64SizeError behavior for valid ceilings. Its effective current diff is exactly src/policy/inlineImagePolicy.ts plus src/policy/inlineImagePolicyPreflight.test.ts; no transport, persistence, authorization, tenancy, credentials, network, model/provider, deployment, retention, durable-audit, or release-publication authority moved into Inkspan.

Test-first lineage

• RED exact test-only head 08257617c496b639d44be09f1a510f9bffa5ef02: hosted CI 31591393025 passed immutable install/typecheck, Office Python 3.11–3.14 and cross-engine setup, then failed at the intended malformed-public-byte-limit repository tests/coverage boundary. Security/SAST on that immediately superseded generation were cancelled and remain non-passing historical evidence.
• GREEN 1c0b2546ce5d8ec152286e392b5d3d7c958c9a25 introduced the finite non-negative safe-integer contract.
• Current exact head f0e1a2e641d5372b4e333361ee015593caeb7cc9 is the non-destructive synchronization of the complete two-file product/test repair onto exact protected main. Predecessor workflow/review evidence does not transfer after head movement.

Exact-current-head evidence

A fresh commit-bound workflow refetch for unchanged exact head f0e1a2e641d5372b4e333361ee015593caeb7cc9 confirms:

• CI 32073713863: completed / success;
• Security Scan 32073713918: completed / success;
• SAST Semgrep 32073713735: completed / success;
• formal submitted reviews recorded by the canonical PR: 0;
• unresolved inline review threads recorded by the canonical PR: 0;
• GitHub reports the Draft mechanically mergeable.

Repository exact-head success is technical evidence only. It does not substitute for separately applicable central workflows, then-live governance, or any qualifying approval requirement. Pending/queued/skipped/cancelled/absent/stale/predecessor/status-only/model-only evidence remains non-passing.

Integration boundary

The behavioral defect is repaired on active Draft #166 but is not protected-main shipped behavior. Keep this issue open until #166 integrates under then-live governance. Keep #166 Draft/unmerged while #118 owns the frozen protected v0.6.0 publication/provenance/digest boundary. Before any lifecycle transition refetch exact head/live base, ancestry/mergeability, formal reviews/threads, live governance and every applicable repository/central workflow. Do not create a competing inline-image writer, transfer predecessor evidence, self-approve, weaken gates, move protected main, or fabricate release identity.