ci: make the verification gates report what they actually ran

[rrrodzilla]

Closes #117.

The first scheduled verification run after #115 unblocked it
(run 30672101564)
failed in two independent ways, neither of them a defect in the crates.
Miri passed in the same run: agent-uri 196 tests, agent-uri-attestation
193 tests, 0 failures, under -Zmiri-disable-isolation.

The fuzz gate installed nothing and went green

Download action repository 'taiki-e/install-action@cargo-fuzz' (SHA:82fc4055…)
INPUT_TOOL:
##[warning]no tool specified; …@<tool_name> tags … replaced by @<version> tags
##[end-action …;outcome=success;conclusion=success;duration_ms=18]

cargo-fuzz is a branch on that action, not a tag, pinned at a commit dated
2024-03-02; cargo-deny resolves to 2026-07-30. The stale code leaves the tool
unset, warns, and exits successfully having installed nothing, after which
all seven targets failed with no such command: 'fuzz'.

The failing jobs are the symptom. The defect is an install step that no-ops
and still reports success. nextest, cargo-deny, and cargo-audit used the
same ref form and work today only because upstream still maintains those
branches — not because of anything this repository controls. All four now name
the tool through with: tool: on @v2.

The kani gate killed its runner having proved 2 of 19

Exit 143, The runner has received a shutdown signal, ~24 minutes in, with no
timeout-minutes on the job. Not a cancellation: miri continued in the same
run for another 25 minutes and passed.

Time	Event
23:10:34	Checking harness proofs::claims_proofs::builder_construction_never_panics
23:10:35	VERIFICATION:- SUCCESSFUL
23:10:45	Checking harness proofs::claims_proofs::builder_missing_issuer_errors
23:33:28	runner killed

Twenty-two minutes in one harness, CBMC unwinding
floor_char_boundary → slice_error_fail_rt → slice_error_fail: the
panic-message formatting for an out-of-bounds string slice.

The harness takes no symbolic input at all, and the one directly below it —
identical but for the .build() call — finishes in a second. build() returns
at the missing agent_key before reaching AgentUri::parse, so the cost is in
what the goto-program contains, not what the concrete path runs. Reading a
harness does not predict its cost.

So this PR fixes the structure and leaves the bounds alone: one harness per job
with timeout-minutes: 20, fail-fast: false. An expensive harness now costs
its own job and is named in the report instead of starving the other 18. The
Kani toolchain cache is extended to ~/.cargo/bin so 19 jobs do not each build
the verifier from source.

This PR does not make the Kani gate green. Whichever harnesses do not
converge will now time out individually, which is the point: that is the data
needed to bound them, and this run could not produce it. Until then a
timed-out harness is an unproved property, not a failed one.

Local runs

task kani runs the whole set, and it has been killing the terminal session it
was launched from — consistent with the same non-convergence meeting the OOM
killer. README and Taskfile now say so, and task kani:harness -- <name> runs
one harness.

Verification

ci.yml parses and the matrix expands to 19 entries across the two crates;
task --list shows both Kani tasks. The gates themselves are workflow_dispatch
only, so they are exercised by dispatching this branch rather than by the PR
checks — results to follow on the PR.