chore(assets): bump boot assets to 0.6.13 (fuse spin-wait, CORE-48)

[AprilNEA]

Bundle v0.6.13 ships kernel v0.0.22 with the FUSE bounded spin-wait (kernel#17) — the CORE-48 fix for VirtioFS metadata round-trip cost.

What users get

Bind-mounted host volumes (docker run -v) — stat/lookup storms on source trees, node_modules, etc:

bench (VirtioFS share)	0.6.12	0.6.13	Δ
metadata_stat	32.1k ops/s	52.8k	+64%
negative_lookup	23.9k	34.3k	+44%
create_delete	4.9k	6.0k	+22%
find_recursive	18.3k	21.6k	+18%
rm_rf	2505 ms	2380 ms	−5%
sequential_read	3771 MB/s	3720 MB/s	±0

The spin is double-gated (virtio-class transports only; blocking opcodes excluded) after kernel#17's review round — full investigation record in Linear CORE-48.

Validation

• boot_assets e2e green on the new bundle (full Docker lifecycle, 116s; CDN download path exercised).
• Per-file hashes verified against the published manifest before staging.
• Daemon rebuilt with the embedded pin (compile-time assets.lock).

[linear-code]

CORE-48

[pullfrog]

✅ No new issues found.

Reviewed changes — a two-line [boot] bump in assets.lock, verified end-to-end against the live CDN.

• Version pin — [boot] version 0.6.12 → 0.6.13, pulling kernel v0.0.22 with the FUSE bounded spin-wait (CORE-48).
• Manifest pin — manifest_sha256 → 7bff7252…. I fetched https://boot.arcboxcdn.com/asset/v0.6.13/manifest.json (HTTP 200, 5775 bytes) and hashed it: byte-exact match with the lockfile value. latest.json also reports 0.6.13.

Checks that passed:

• Manifest delta is exactly what a kernel bump should be. Diffing 0.6.12 against 0.6.13 moves only asset_version, built_at, source_ref (latest → v0.0.22), the kernel/rootfs/runtime sha+path for both arches, and a rebuilt FEX (FEX-2605-0.6.13). No silent tool-version churn rode along.
• The assets.lock header rule is satisfied. The bundle's dockerd, containerd-shim-runc-v2, runc and docker-init all stay at 29.6.1, matching the [[tools]] docker pin, so the two sides do not diverge. k3s v1.36.2+k3s1 still lines up with kubectl 1.36.2.
• No drift surprises beyond the intended recreate. schema_version is still 0, kernel_cmdline is unchanged, and the per-arch runtime target is still present — so DesiredBoot::expected_disk_count() stays at 4 and the only drift existing machines see is the versioned kernel path, which is the mechanism that delivers the new kernel.
• No stale references. Nothing tracked still mentions 0.6.12, and no committed baseline*.json or repo code depends on the manifest's kernel version string.

ℹ️ The measured win isn't captured anywhere the repo can defend

The +64% metadata_stat / +44% negative_lookup numbers live only in this PR description. tests/bench-virtiofs already supports --compare baseline.json --fail-on-regression, and tests/e2e/tests/bench_virtiofs.rs says outright that it "measures and records; it does not assert a ratio (there is no baseline yet to regress against)". Nothing blocking here and nothing to change in this diff — but this bump is the cheap moment to commit a baseline, since the before/after pair exists right now and won't after the next bump.

Technical details

# VirtioFS perf baseline is uncaptured at the moment it's cheapest to capture

## Affected sites
- `tests/e2e/tests/bench_virtiofs.rs:8-9` — module docs state the test records
  results but asserts no ratio, "there is no baseline yet to regress against".
- `tests/bench-virtiofs/README.md:34-36, 80-85` — the `--compare baseline.json
  --fail-on-regression --threshold N` mechanism already exists and is documented
  as CI-wireable, but no `baseline*.json` is committed anywhere in the repo.
- `assets.lock:17` — each bump replaces the artifacts that produced the numbers,
  so the 0.6.12/0.6.13 pair is only measurable until the next bump lands.

## Required outcome
- The 0.6.13 VirtioFS figures are recorded somewhere durable enough that a later
  kernel or rootfs bump which regresses them is detectable, rather than living
  only in a PR description.

## Suggested approach (optional)
- Commit the 0.6.13 guest-side JSON report from `bench_virtiofs` as the first
  `baseline.json`, so a future bump can run `--compare baseline.json`.
- Or, following the `docs/net-perf-limits.md` precedent for recorded measured
  ceilings, write the pre/post table into a short docs note pinned to bundle
  version + kernel ref.
- Either is follow-up work; this PR does not need to grow.

## Open questions for the human
- Were guest and host CPU costs measured alongside the throughput wins? A
  bounded spin-wait trades CPU for latency, and idle CPU / RSS are headline
  metrics in the root `CLAUDE.md` table. The spin should be inert at idle (it
  only spins with a FUSE request outstanding), so this is about behaviour under
  heavy metadata load (`docker build`, `node_modules` trees) rather than a
  regression I observed — the CORE-48 record likely already has the numbers.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}