Renewal ledger has no reader and no untrack

[TarikGul]

The statement-store renewal ledger can only be appended to. A host can add targets and run a pass, but cannot see what is tracked or remove anything.

track_targets appends and dedupes. Nothing in the workspace clears CoreStorageKey::StatementRenewalTargets, and there is no list, read or untrack on SigningHostRuntime or on the native surface. The only removal is implicit: owned_targets drops entries promised by a different root identity during a pass.

Why it matters

A wrong or stale entry is permanent for the life of the identity, and every period it consumes one of the host's slots. Slots are finite: LiteStmtStoreSlotsPerPeriod reads 10 on paseo-next-v2, so a handful of dead entries measurably reduces what a host can actually keep allowed, and the pass reports exhaustion rather than the cause.

A host also cannot audit its own state. If a product asks why its allowance lapsed, there is no way to answer beyond running a pass and reading the outcomes.

Raised three times in review, on #417 twice and on #423.

Already done

#423 reports dropped labels in StatementRenewalReport.pruned and logs them at the prune site, so the silent case is covered: a host learns that an entry went away and can re-track it. That is the detection half. This issue is the rest.

Decisions needed

These are the reason this is an issue rather than a PR. Each changes the shape of the API, and freezing the wrong one is worse than waiting.

1. What does a reader return? Raw ledger entries are inspectable with no session, which suits a cold-started background task. Resolved targets carry account ids and are more useful, but resolution needs root entropy, so the call would fail exactly when a scheduled host most wants to inspect state.

2. How does untrack identify an entry? LedgerEntry equality includes the label, so Account { id, "device" } and Account { id, "Device" } are distinct entries pointing at the same account. Untrack by value would surprise, and untrack by index couples callers to ledger ordering.

3. Is a reader still worth its surface now that pruning is reported? If the answer is that hosts only ever needed to know about drops, feat(server): report renewal targets dropped by an identity change #423 may already be enough and only untrack is missing.

4. Should untrack be able to remove another identity's entry? Pruning handles that during a pass, so an explicit untrack scoped to the active identity may be the whole requirement.

Scope note

Whatever shape is chosen lands on NativeTrUApiHostRuntime and NativeTrUApiCore, both host shells, and the committed Swift bindings, so it is worth agreeing before writing it. Worth pulling in whoever owns the iOS and Android integrations, since they are the consumers.