Storage Resilience Quick Wins

### What is this about?

## Goal

Track the small, independent storage-resilience tasks listed in this issue.

## Tasks

- [x] [`waitUntil` to ensure all scripts load](https://github.com/MetaMask/metamask-extension/issues/43773) — `waitUntil` was investigated and does not solve this.
- [ ] [`waitUntil` to ensure async storage writes finish before the service worker terminates](https://github.com/MetaMask/metamask-extension/issues/43774) — the `waitUntil` attempt failed; the underlying shutdown-write goal remains open.
- [ ] [Set IndexedDB durability mode to `strict` (not `relaxed`)](https://github.com/MetaMask/metamask-extension/issues/44741)
- [ ] [Detect outliers in storage footprint / write volume](https://github.com/MetaMask/metamask-extension/issues/44250) — tracked by E0.
- [ ] Re-word error messages to deflect blame from user hardware where appropriate — no matching current message was found in the storage-error or corruption UI. This needs the exact message or code path before we open an issue.
- [x] [Automatic write retry after failure](https://github.com/MetaMask/metamask-extension/issues/44681)
- [ ] [Reconsider the background-connection health check before adding a retry](https://github.com/MetaMask/metamask-extension/issues/44742)

## Tracking decisions

Keep each task separate. Reuse #43774 and #44681, merge the storage-outlier work into E0, and do not open an error-copy issue until the original author identifies the current message that needs changing.

## Open questions

- Which IndexedDB backup transactions should request strict durability?
- Is the current `ALIVE` check still useful, or should it be simplified, replaced, or removed before adding a retry?
- Which current error message was the error-copy task referring to?

### Scenario

_No response_

### Design

_No response_

### Technical Details

_No response_

### Threat Modeling Framework

_No response_

### Acceptance Criteria

- [ ] Every task links to an existing issue, another storage-resilience epic, or a recorded decision not to open an issue.
- [ ] Each child issue matches the current code path it intends to change.

### 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 epic: #44248
- Exploratory retry PR for #44681: #44003
- Exploratory shutdown-write PR for #43774: #44610

The linked PRs are research and may or may not become the final implementation.

Start by reviewing the linked child issues #43774, #44741, #44250, and #44742, along with parent epic #44248 and the exploratory PR references. Done means each task is linked to an existing issue, epic, or recorded decision, and each child issue matches the current code path it intends to change.

Written by the indexing model from the issue text.