skills: add pi-devbox-firstboot, and point the managed AGENTS block at it

The fleet's first-boot acceptance round is now scoped by published state
(policy v2, artifact art_20261023T204306_b388e93c3d64): a booting container
reads two claim keys -- firstboot-release-<TAG> and
firstboot-image-<TAG>-<ARCH> -- and derives whether it owes the release tier,
the per-architecture image tier, or only the device tier.

Nothing delivered that procedure to a device that does not already have a
coordination chain. The gate deliberately needs no roster, because fleet
membership changes in both directions, so no message addresses a new device and
nothing enrolls it. The consequence is that a BRAND-NEW device -- empty
mailbox, no chain, and the mempalace skill correctly telling it that an empty
mailbox is a fine answer -- had no path to the round at all. Historically a
peer planted the newcomer's first ask cross-device, which is exactly the roster
dependency the state design removes. This skill is how a device learns to plant
its own.

The skill is a FINDER, not the policy: it locates the newest policy.update on
topic=firstboot-acceptance and fetches the artifact, and says plainly that the
artifact wins on disagreement. A policy baked into an image is pinned to that
image; keeping only the lookup here means a revision needs no release and a
device on an older image still reaches the current policy.

Baked canonical, like pi-devbox-environment, rather than skillset-owned. The
round verifies the image, so pinning it to the image is right -- and a
skillset-owned skill needs the vendoring machinery (ARG SKILLSET_SNAPSHOT_REF,
the manifest/label pair, a per-skill refresh script) that today exists only for
mempalace. No wiring was needed: entrypoint-user.sh and pi-devbox-version both
enumerate the baked skills directory.

smoke-test.sh asserts the AGENTS.md pointer BY PATH, not by prose. A new device
reaches the round only through that line, so rewording the paragraph must not
be able to cut it silently. Both skill-resolution loops gain the new name.

README.md

@@ -804,7 +804,14 @@ directory, and they compose:
   mechanisms, the interactive-vs-tool-shell alias gotcha (`dssh`/`dscp`),
   tmux 0-indexing, uv-first Python, and pi-studio reachability, all as
   *mechanisms* (deployment-specific hostnames/domains/nameservers are
-  discovered at runtime, never hardcoded).
+  discovered at runtime, never hardcoded). **`pi-devbox-firstboot`** ships the
+  same way and is the entry point to the fleet's first-boot acceptance round:
+  it carries the *state-based scope gate* (two claim lookups, keyed by release
+  tag and by architecture, deciding which tiers of checks this device still
+  owes) rather than the policy itself, which it locates in the logstream so a
+  policy revision needs no release. Baked rather than skillset-owned on purpose
+  — the device that most needs it is a brand-new one with an empty mailbox and
+  no coordination chain, so nothing would deliver it.
 - **Vendored fallback skills.** The pi-toolkit global `AGENTS.md` tells every
   pi session to read `~/.agents/skills/pi-extensions/SKILL.md` at start (to fix
   fork/recall under-utilisation). That pointer would dangle in a container
@@ -1124,6 +1131,7 @@ pi-devbox v1.8.14
     credential-incident-response baked
     mempalace              live /workspace/skillset @ 4d7c0ea  (identical to baked snapshot)
     pi-devbox-environment  baked
+    pi-devbox-firstboot    baked
     pi-extensions          baked
 ```