## Problem `audit_trail_tsa` writes two State keys and ships no `.install`, so nothing ever deletes them: - `audit_trail_tsa.last_run_at.<chain>`, the per-chain timestamp throttle (`AuditTrailTsaCronHooks`). - `audit_trail_tsa.highest_assigned_tsa_id`, the floor `AuditTrailTsaProvider::getNextTsaId()` reads (`AuditTrailTsaProvider`). The parent module already settled what to do with keys like these. `audit_trail_uninstall()` sweeps its own per-chain prefixes, and `UninstallStateTest` says why the sweep matters: *"reinstalling is the supported way to move between the alphas, so the uninstall is a step real sites take rather than a teardown"*, and *"without a name for it, nothing the module ships can ever delete that row"*. It deliberately exempts one key, the secret-id floor, because *"a reissued id points an archived range at bytes that did not sign it"*. Neither rule reaches the submodule. `audit_trail_uninstall()` sweeps by prefix and the submodule's prefixes are `audit_trail_tsa.`, not `audit_trail.`; and the submodule has no uninstall hook of its own. So uninstalling `audit_trail_tsa` leaves one row per chain behind, permanently. The test that would have caught it cannot see it either. `UninstallStateTest::scanStateConstants()` reflects over three parent-module classes and filters on values starting `audit_trail.`, so the submodule's constants are out of scope twice over. That is why this survived: the check exists, and its scope stops at the module boundary. ## Consequence Small, and in two parts. A row per chain left in `key_value` for good, which is what the parent's sweep exists to prevent. And a stale throttle across a reinstall: `cron()` reads `last_run_at.<chain>` before doing anything, so a freshly reinstalled `audit_trail_tsa` inherits the previous install's stamp and does not timestamp that chain until the interval has elapsed from a run that belongs to an install that is gone. On the shipped daily interval that is up to a day of a fresh install quietly not anchoring. ## Fix `audit_trail_tsa.install` with an `audit_trail_tsa_uninstall()` that deletes the per-chain throttle keys, enumerating chains the way the parent's does, and keeps `highest_assigned_tsa_id` for exactly the parent's reason: a reissued `tsa_id` resolves every stored `tsa_timestamp` row to another provider's pinned CA chain, so those timestamps would be verified against the wrong authority. `UninstallStateTest` gains the submodule's State-declaring classes, and its scan stops filtering on the parent's prefix, so the next key added anywhere in the project is checked rather than assumed. ## Test coverage `TsaUninstallStateTest` pins both halves the decision rests on: the throttle key goes, and `audit_trail_tsa.highest_assigned_tsa_id` survives. Confirmed to fail against the unfixed code (`audit_trail_tsa.last_run_at.webdav belongs to the install that is gone`) and to pass with the change. It scans this submodule's State-declaring classes rather than listing its keys, so a key added later and forgotten in the uninstall fails there. It is a class of its own rather than a case in `UninstallStateTest` because that scan reflects over three parent classes and filters on the parent's prefix: these constants were out of its scope twice over, which is the reason nothing caught this. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the fix and its tests. I reviewed both, and the new tests were confirmed to fail against the unfixed code and to pass with the change.)