feat(figma): retrieve original image bytes through the bridge

[owjs3901]

Two screens worked in parallel. One gained a capability, one gained an explanation. Neither claims a pixel improvement, and both say so.

1. Original image bytes are now retrievable

A CROP fill names its source by hash, but nothing could fetch the pixels behind that name. The official MCP returns text only, so the bytes had no transport; the connector tool that would supply them answers UNAUTHORIZED and belongs to the metered path anyway.

The bridge has no such limit - a local socket where nothing is truncated. A read-only getImageByHash route now retrieves the selected fill's original bytes with their intrinsic codec, never a whole-node rendition, and decodes and verifies them against the declared hash.

The remote path refuses outright, with a named reason. That refusal is the more valuable half: a silently wrong image is worse than a missing one.

No document is mutated. The temporary-rectangle technique that would have produced an isolated rendition creates and removes nodes, and was rejected for exactly that reason.

What is not claimed

The isolated-fill renderer that would consume these bytes is not implemented, and about-422-3376 is unchanged at 5.43%. Capturing live source bytes requires re-importing the rebuilt plugin in Figma - a desktop menu action neither the worker nor I can perform. The report names the exact capture (file f1AJyo27afkkr6U9PhnWSu, node 422:3378, fill 0, hash 09939a0d…, and the call) so nobody has to re-derive it.

This corrects an earlier diagnosis, too: the previous cycle read UNAUTHORIZED as "our token needs reauthentication". It does not - devup_figma_auth { doctor } reports connected with a valid token. The failing request was the metered connector's download_assets, and the route that does work was named in that same report and had simply never been implemented.

2. Landing mobile, quantified rather than fixed

landing-833-3640 sits at 4.78%. With identical DOM geometry, a Chromium probe with LCD subpixel antialiasing disabled measures 2.91% (and 1.61 / 1.03 for its siblings, against 2.47 / 1.50).

That attributes a large share of this screen's divergence to font rasterisation, not to generated layout. Default-probe PNGs are byte-identical to the harness, so this is a property of the comparison, not of the code under test. Production is unchanged and no improvement is claimed; residual glyph advances still need separate evidence.

Worth absorbing corpus-wide: after nine cycles of real layout fixes, a meaningful part of what remains may be the renderer, not the generator.

Verification

Gates: fmt 0, clippy --locked --workspace --all-targets --all-features -D warnings 0, cargo test --workspace 1122 passed / 0 failed / 2 ignored (main is 1118), insta --check no drift, plugin bundle rebuild clean.

All 14 measurable screens re-measured by me: identical to main. All 268 plugin byte-parity goldens unchanged. Korean keep-all untouched. No threshold moved - correctly, since nothing improved.