A data: URI carries its own bytes

[CagdasErturk]

A document that wants to be one file embeds its binary as an RFC 2397 data: URI, and nothing in this tree could decode one. This adds the decoder as a layer of its own: a URI in, bytes out, the media type reported rather than judged, and no filesystem access.

The rule it is built on is that a difference which cannot change an output byte is forgiven and one that can is refused. The ;base64 marker is read in any letter case. Whitespace, the URL-safe alphabet, a payload that is not whole four-character groups, and padding anywhere but the end are refused, and the three refusals that are about one character carry its offset.

The one that is easy to miss is the final group's unused bits: QQ== and QR== would both decode to the single byte A, because the last four bits of the second character reach no output byte. Accepting both lets two different texts name one resource, so only the first is accepted.

Seven refusals, all reachable, each named and each provoked. Forty-four seeds, one per rule on both sides of it, with the replay gate the other readers here have. Five property tests, including one that alters a single character of an encoded payload and requires the result to be refused or to decode to something different.

Four review passes rejected the first version of this, and the checks were green throughout. The last commit is what came of them, and two findings are worth naming here because neither is visible to a gate — both pass:

• The fuzz target had never run and could not. A URI with no parameters returned an empty string literal, which is a static pointer borrowing nothing, and the target asserts by address that both text fields are views into the URI. It aborts on eighteen of the twenty seeds it accepts — every ordinary embedded buffer. The empty tail of the description is a view; an empty literal is not. A test now pins provenance for both fields in both shapes.
• Two property tests asserted nothing. Both generated arbitrary bytes, which begin with the scheme essentially never, so both only reached the first refusal and one ran its assertion zero times. There is a generator now, and a test that measures the generator.

Nothing would have caught the first of those, because the target is in no matrix. Seven targets were declared, given corpora and run by nothing: obj_read, mtl_read, blob_read, glb_read, accessor_view, gltf_read and this one. All seven are scheduled now, and a check requires every declared target to be there.

The alphabet is a lookup table generated at compile time from the match that already spelled it, which measured about four times the throughput of the ranges on a payload of the size this reader is documented to expect. Two tests pin the generation: every entry against the match it came from, and the alphabet as a bijection onto the six-bit values.

REFUSALS.md gains rows for three readers that landed with fuzz targets and never reached it, and its per-reader counts are re-measured — the first attempt used a parser that could not see a match arm with a block body.

Local gates seen on the final commit: cargo fmt --all --check clean, cargo clippy --workspace --all-targets -D warnings clean, cargo test --workspace 264 suites / 2,932 passed / 0 failed, renew check reports the workspace healthy, and scoped coverage over renew-mesh puts the new module at 100% of lines and 100% of regions. The fuzz target itself cannot be run locally — cargo fuzz needs nightly and this workspace is stable-only — which is exactly why it now runs on the schedule.