Apply the open H3 fixes to the prebuilts we publish

[danielhanchen]

The three MiniMax-H3 fixes on master (#2, #3, #4) currently reach nobody.

unsloth-sd-prebuilt.yml builds leejet's source at an aged release tag, not this fork's master, so every binary the Studio installs still aborts on the default --cfg-scale, still aborts on --vae-on-cpu, and still quantizes H3's 1-D norms into an output uncorrelated with its own bf16 reference. All three are open upstream (leejet#1861, leejet#1862, leejet#1863) but none is in a release yet.

Building from master instead would throw away the reason the pipeline is shaped this way: what we publish should be traceable to a specific upstream release, not to whatever a fork happened to contain that day. So this keeps the upstream tag as the base and carries the delta explicitly.

How it works

• patches/ holds one file per fix, each with its upstream pull request in the header, plus a README with the rules.
• resolve applies them to the checked-out tag, after running git apply --check over the whole set first, so a stale patch stops the run before the tree is half modified.
• A non-empty set moves the published tag to <upstream tag>-u<id>, where <id> is the sha256 prefix of the concatenated patches. So the tag says whether a box is stock, and changing the patch set republishes instead of matching an existing release and skipping.
• sd-prebuilt-manifest.json and the release notes both record the applied list. source_commit stays the upstream commit.

An empty patches/ leaves the tag, every asset name and the manifest exactly as they are today, so the normal steady state is unchanged.

Why a failing patch is the point

git apply --check failing is the designed signal, not a breakage to route around: upstream either merged the fix, in which case the file gets deleted, or moved the code under it, in which case it gets refreshed and re-verified. Without that the next release would silently ship a duplicate of code upstream already has.

Verified

Ran the resolve step verbatim against master-813-bfbef5b with gh stubbed:

applied 0001-spare-1d-norm-weights-from-blanket-quant.patch
applied 0002-h3-cfg-scale-and-audio-vae-on-cpu.patch
applied 0003-h3-img-gen-mode-guard.patch
patched build: master-813-bfbef5b + 0001...,0002...,0003... -> master-813-bfbef5b-u0665242
stamped source for master-813-bfbef5b-u0665242 (f7007b096ded799a9ecac405cc27a177fb6bc1f3)

• the stamped source tarball contains all three fixes,
• with patches/ empty the tag stays master-813-bfbef5b and the outputs are byte-identical to today,
• breaking one patch the way an upstream refactor would stops the run with the patch name, leaves the tree unmodified, and emits no outputs, so no downstream job can publish,
• assemble_metadata.py records upstream_tag and patches, and a stock build still gets upstream_tag == tag with an empty list.

The binaries themselves were verified end to end before the three fixes were merged: a CUDA build of master renders at --cfg-scale 7 (warns and clamps), renders with --vae-on-cpu alone and combined with --offload-to-cpu --clip-on-cpu, and errors cleanly instead of core dumping when --mode vid_gen is omitted.