Change the controller persistence cadence and keep Keyring writes immediate

**What is this about?**

`safePersist` uses a shared one-second operation-safener window. E4 proposes a five-second gate with a 30-second maximum wait. PR #44009 describes a 30-minute maximum wait, which does not match this proposal. The cadence must be controlled by a feature flag so the experiment can compare configurations and restore the one-second behavior without a new release.

## Goal

Measure whether a five-second persistence gate with a 30-second maximum wait changes write volume or corruption-event rates.

## Before implementation

Before writing code, try to prove this issue is not worth doing. Make the requirement less dumb before optimizing anything. Look for code, state, or writes we can delete. If deletion does not solve it, prefer a smaller change using what already exists. Record the finding and close the issue if the proposal no longer makes sense.

## Open questions

- Which KeyringController changes must bypass the gate?
- What feature-flag value controls the persistence window and maximum wait?
- Which #44250 fields identify the effective cadence for the write and corruption measurements?
- How will a corruption event at startup be associated with the cadence used for the preceding writes if primary storage cannot be read or the remote flag has not loaded?

**Technical Details**

The experiment is blocked on the write, corruption, and dashboard work in #44250.

**Acceptance Criteria**

- [ ] The feature flag can select the one-second control or the five-second gate with a 30-second maximum wait.
- [ ] A missing or invalid flag value uses the one-second control.
- [ ] The experiment can return to the one-second control without a new extension release.
- [ ] KeyringController writes flush immediately.
- [ ] The #44250 instrumentation records the effective cadence for each experiment cohort.
- [ ] A startup corruption event can be associated with the cadence used for the preceding writes even when primary storage cannot be read.
- [ ] The #44250 dashboard compares write volume and corruption-event rates between the control and experimental cohorts. It compares rates rather than raw event counts.
- [ ] The issue records the measured result before the experimental cadence is expanded or made the default.
- [ ] Tests cover coalescing, maximum wait, Keyring ordering, and write failure.

**Stakeholder review needed before the work gets merged**

- [ ] Engineering (needed in most cases)
- [ ] Design
- [ ] Product
- [ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
- [ ] Security
- [ ] Legal
- [ ] Marketing
- [ ] Management (please specify)
- [ ] Other (please specify)

**References**

- Parent: #44253
- E0 measurement: #44250
- Exploratory PR: #44009

The linked PR is exploratory. Linking it here does not select an implementation.

Start by reading safePersist and KeyringController, then review #44250 and exploratory PR #44009; the issue is explicitly blocked on their write, corruption, and dashboard work. Done means the flag safely selects both cadences, Keyring writes remain immediate, required tests pass, and the experiment records and compares effective cadence, write volume, and corruption rates.

Written by the indexing model from the issue text.