ledger: Rekor v2 hashedrekord anchoring backend

[JSONbored]

Context

Sub-issue of #9267 (external decision-ledger anchoring). Primary anchoring backend, per the research on #9267: Rekor v2's hashedrekord accepts a plain hash + signature — content-agnostic, Rekor never sees the payload itself — and needs zero new dependencies since ECDSA P-256/SHA-256 is native to Workers via crypto.subtle.

Requirements

1. Submit POST /api/v2/log/entries with a hashedRekordRequestV002: base64 SHA-256 digest of the canonicalized anchor payload (ledger: versioned + signed anchor payload, public key + rotation route #9270), signature over the payload bytes, and the verifier public key (SPKI DER) + keyDetails: PKIX_ECDSA_P256_SHA_256. No Fulcio, no OIDC — the self-managed key from ledger: versioned + signed anchor payload, public key + rotation route #9270 is what verifier.publicKey expects.
2. Do not hardcode a log URL. Shards rotate annually (log2025-1, log2026-1, ...); resolve the current shard at call time or via a small pinned config, not a literal constant that goes stale.
3. Store the full response: logIndex, logId.keyId, kindVersion, inclusionProof (hashes + signed checkpoint), canonicalizedBody — this is what makes verification possible fully offline later, without trusting Rekor's continued availability.
4. Timeout ≥ 20s — v2 batches submissions; a short timeout will falsely read as failure.
5. On any error, write a status: 'failed' row via ledger: anchor persistence + public attempt log (success and failure both visible) #9271's persistence — this backend must never throw in a way that blocks the anchoring job from also trying ledger: Rekor v2 hashedrekord anchoring backend #9272.

Deliverables

• Rekor v2 submission implemented against the anchor payload from ledger: versioned + signed anchor payload, public key + rotation route #9270, persisted via ledger: anchor persistence + public attempt log (success and failure both visible) #9271
• Tests: successful submission stores every field needed for later offline verification; a submission failure (timeout, non-2xx) records a failure row and does not throw past the caller
• Documented offline-verification procedure (checkpoint signature against the sigstore trust root, then Merkle inclusion, then digest match) in this issue's own PR

Expected outcome

Every checkpointed anchor carries a Rekor entry independently verifiable by anyone, including fully offline, without contacting LoopOver.

References

Sub-issue of #9267. Depends on #9270 (payload), #9271 (persistence). Full mechanism research + example request/response shapes: decision-record comment on #9267.

[linear-code]

JSO-6435