Mint identifiers through one helper instead of 109 inline Ulid::new() calls

## What

`Ulid::new()` reaches `rand::rng()`, which panics if the operating system
cannot supply entropy. The workspace calls it in 109 places across 31 files,
and every one of them mints an identifier the same way: inline, infallibly, at
the point of use.

Review of #682 asked for one of those call sites
(`registry-platform-authcommon/src/client_assertion.rs`, the RFC 7523 `jti`) to
become fallible. Fixing that site alone is not worth doing, and the reasoning
is why this issue exists rather than a patch on that branch.

## Why the single-site fix does not help

In the Evidence request path the assertion `jti` is not the first ULID minted.
`OperationId::new()` (`registry-evidence/src/observability.rs:80`) mints one at
the request boundary before any handler runs, and `audit.rs:95`, `audit.rs:238`,
`runtime.rs:1265`, and `main.rs:2532` each mint more. If entropy is
unavailable, the process has already panicked by the time the token exchange is
reached, so a `Result` on the `jti` would ship as an error variant no test
could reach.

The blast radius today is bounded and fail-closed: the workspace sets no
`panic = "abort"` and installs no catch-panic layer, so the panic unwinds at
the tokio task boundary, kills one request, and returns no assertion. The
process keeps serving, and the failure is loud rather than silent.

There is also existing precedent for leaving this unguarded deliberately, with
the reasoning written down: `registry-evidence-client-py/src/lib.rs:548-562`
and its `README.md:104-114`.

## What would actually be worth doing

If entropy failure is to be a handled condition rather than a panic, it has to
be handled once, for every identifier the stack mints:

- A single id-minting helper in a `registry-platform-*` crate that every call
site uses, so the policy lives in one place.
- A decision on what the policy is: fail the request with a typed error, or
keep panicking but do it at a named seam. Either is defensible; having 109
independent inline decisions is not.
- A test seam that can simulate entropy failure, so whichever policy is chosen
is actually covered rather than asserted.
- A sweep converting the call sites, including the audit and observability ones
that run before any handler.

## Scope

Workspace-wide, not Evidence-specific. Availability hardening under a hostile
or misconfigured host environment; not a correctness, disclosure, or
minimum-disclosure concern. No known deployment has hit it.

Spun out of review on #682, where the narrow fix was declined for the reasons
above.

Inizia leggendo registry-evidence/src/observability.rs:80, verifica audit.rs:95 e :238, runtime.rs:1265 e main.rs:2532, quindi esamina il precedente in registry-evidence-client-py/src/lib.rs:548-562 insieme a README.md:104-114. Decidi la policy di gestione dei fallimenti e il test seam, poi fai l’inventario dei 109 punti di chiamata; il lavoro è completo quando ogni mint usa un helper e il fallimento dell’entropia è coperto dai test.

Scritto dal modello di indicizzazione a partire dal testo della issue.