fix(ci): pin cargo-lambda to 1.9.2 so the arm64 lambda links under Rust 1.98

[MichaelTaylor3d]

Task

The main tip of on.dig.net (f6bd45de, v0.5.11) is RED on deploy, which freezes the superproject
gitlink pointer. This unfreezes it by fixing the actual break and adding the gate that would have
caught it before merge.

Root cause (not the symptom)

Deploy run
32498562051 failed at
cargo lambda build --release --arm64:

error: unsupported linker arg: --fix-cortex-a53-843419
error: could not compile `on-dig-net-resolver` (bin "bootstrap")

Nothing in this repo changed to cause it. The two inputs were compared across runs:

run	date	rustc	cargo-lambda / ziglang	result
31422779156	2026-08-10	1.97.1	1.9.1 / 0.16.0	success
32498562051	2026-08-21	1.98.0	1.9.1 / 0.16.0	failure

Rust 1.98.0 (released 2026-08-20) began emitting -Wl,--fix-cortex-a53-843419 in the link args
for aarch64-unknown-linux-gnu. Zig's linker rejects that flag. cargo-zigbuild filters it as of
0.23.0 (rust-cross/cargo-zigbuild#452), and cargo-lambda picked that up in 1.9.2
("fix: support Rust 1.98 ARM64 builds", cargo-lambda/cargo-lambda#937, published 2026-08-21) —
cargo-lambda 1.9.1 bundles cargo-zigbuild 0.20.1, which does not filter it.

So this is a floating-toolchain drift: toolchain: stable moved under an unpinned
pip install cargo-lambda ziglang, and the two lines crossed.

Live service impact: NONE

The resolver is up and answering. https://test.on.dig.net/ returns 404 from the Lambda with the
resolver's own headers (X-Dig-URN, X-Dig-Store, X-Dig-Root in
access-control-expose-headers), i.e. an unregistered-subdomain answer from live code, not an
infrastructure error. The apex on.dig.net has no record by design; *.on.dig.net resolves to its
own CloudFront distribution. The failed deploy left the live Lambda at the v0.5.10 build rather than
breaking it — the v0.5.11 URN-parser conformance change (#18) is what has not reached production.

The fix

1. Pin cargo-lambda==1.9.2 and ziglang==0.16.0 in deploy.yml. 1.9.2 carries the
   cargo-zigbuild uplift that filters the flag. Both are now pinned rather than floating, so this
   class of break arrives as a deliberate bump instead of arriving on its own at deploy time.
2. Add a lambda-build CI job performing exactly the cross-compile deploy.yml performs, minus
   AWS. This is the regression test: the gap that made this a deploy-time discovery was that the
   arm64 build existed in no PR gate, so every check was green on a tip that could not deploy.

Regression test evidence (§2.2)

The gate was pushed FIRST, without the fix, and observed failing for the right reason on c8f43d5 —
unsupported linker arg: --fix-cortex-a53-843419, the same error as the deploy run. The fix commit
then turns it green. Both run ids are recorded in a comment on this PR.

Blast radius

CI/deploy workflow only. No Rust, Terraform, or asset changes; no change to the resolver's behaviour,
its CloudFront distribution, its asset bucket, or its Lambda configuration. on.dig.net's dedicated
infrastructure is untouched.

Out of scope, reported not fixed

This crate is on the chia 0.26 line (chia-protocol/chia-bls/clvm-* 0.26.0) while the
ecosystem has moved to 0.36. §2.4b would normally have this PR bring those current, but that is a
type-identity change across the resolver's URN/puzzle-hash paths and does not belong in a PR whose
job is to unfreeze a red deploy. Filed separately.

[MichaelTaylor3d]

Reproduction evidence, stated honestly

The regression gate was pushed first, without the fix, on c8f43d5 — and it passed
(run 32673740675).

That is not the gate failing to work. pip install cargo-lambda is unpinned, and cargo-lambda
1.9.2 was published on 2026-08-21, hours after the deploy that failed. By the time the gate ran,
the floating install already resolved to the fixed version, so the historical break was no longer
reproducible through an unpinned install.

The diagnosis is confirmed by the version differential instead, which is stronger than a single
reproduction because it isolates the one variable:

run	rustc	cargo-lambda	ziglang	arm64 link
31422779156 (deploy, 08-10)	1.97.1	1.9.1	0.16.0	success
32498562051 (deploy, 08-21)	1.98.0	1.9.1	0.16.0	failure
32673740675 (gate, 08-23)	1.98.0	1.9.2	0.16.0	success

Same zig throughout. Rust moving 1.97.1 to 1.98.0 breaks it; cargo-lambda moving 1.9.1 to 1.9.2
fixes it. That matches cargo-lambda#937 ("fix: support Rust 1.98 ARM64 builds") exactly.

This is the strongest argument for the pin, not against it. Before this PR, both the deploy step
and the new gate installed whatever pip resolved to at the moment they ran — so the gate could pass
on one version and the deploy fail on another, which is precisely how the break reached production
with every check green. Pinning both steps to cargo-lambda==1.9.2 and ziglang==0.16.0 is what
makes the gate's green mean something about the deploy.

Fix commit 95de0d2 is green on all seven
required contexts, and arm64 lambda cross-compile (mirrors deploy.yml) has been added to branch
protection's required set — an added gate that is not required would not have blocked anything.