Skill: prove an extension boot sequence, not just its duration

**Size:** M | **Domain:** `platform`

---

## Problem

Nothing validates the extension's boot path. `C1 startup / custom traces` in the evidence catalog measures how *long* startup takes; nothing checks that it happened in the right **order**, that split init scripts ran in the declared sequence, or that a change to `app/scripts/load` preserved the contract.

MV3 makes this load-bearing. The service worker is evicted and restarted constantly, so the boot path runs far more often than a page load ever did, and a reordering that appears harmless in a warm session surfaces as a cold-start failure a user cannot reproduce.

`extension-lifecycle-decoupling` (#44) documents the lifecycle and corrects the assumptions people make about it — no `onSuspend` lock handler, alarms-based timers surviving restart, state persisted in `chrome.storage.session`. What it cannot do is prove a given boot path is intact after a change.

---

## Solution

An engine skill that proves a boot-sequence claim, in the shape the catalog's other engines use.

**The falsifier is the whole problem here:** a boot assertion satisfied by a *warm* start, where the phase under test never ran. That failure mode is silent and reads as a pass, exactly like the vacuous-green cases `falsifying-test` exists to catch. So the skill's first obligation is proving the cold path was actually exercised before interpreting any assertion.

Scope to cover:

- Init-script order, against the declared sequence rather than against whatever ran
- Cold start distinguished from warm, with the distinction asserted, not assumed
- What must be available by the end of each phase, and what must not be touched before it
- Behaviour across service-worker eviction, which is the common case rather than the edge case

---

## Acceptance criteria

- [ ] Proves the cold path was exercised before any assertion is read
- [ ] Asserts init order against the declared sequence, naming the source of truth
- [ ] Distinguishes cold start from warm start explicitly
- [ ] Worked example on a real change to `app/scripts/load`
- [ ] Renders no ship verdict; reports what held and what did not

---

## Notes

Fills a genuine hole: of the boot- and build-adjacent lanes, `D1`, `D4`, `D5`, `F8`, and `C1` have no engine skill, and boot *order* is not a lane at all.

Suited to whoever owns the load path — the recent history there is concentrated in `app/scripts/load` and the init-script split.

---

Tracked in Jira as `AIENG-94`.

Start by reading the boot path in app/scripts/load and the init-script split, then review the evidence catalog's existing engine shapes, including C1 startup / custom traces. Define how the skill proves a cold path ran, checks the declared init order, and distinguishes cold from warm starts across service-worker eviction. Validate it with a worked example using a real change to app/scripts/load; the result should report what held and what did not, without a ship verdict.

Written by the indexing model from the issue text.