fix(006): pin @statecrafting/fleet-native 0.2.0, the per-app ingress allow

[bartekus]

What

Bumps the @statecrafting/fleet-native pin from 0.1.0 to 0.2.0 and records the 2026-07-23 in-pod two-stage fleet E2E in spec 006 as a dated amendment.

The E2E placed two apps on two different ports in one tenant namespace (echo on 4000, the private enrahitu chassis on 8080) and surfaced the namespace-wide port pin: the addon's fleet-allow-ingress-nginx NetworkPolicy was namespace-scoped but pinned the deploying app's single port under create-or-tolerate-409, so the first app froze the allowed port set. The chassis rolled out Ready (kubelet probes bypass NetworkPolicy) and served 502 from the edge; the live policy was hand-patched to admit 8080 as mitigation.

fleet-native 0.2.0 (statecrafting spec 006 amendment, statecrafting/statecrafting#12) makes the ingress allow per-app (fleet-allow-ingress-<app>, podSelector on the app's selector labels, exactly the app's port) and removeApp deletes it with the app's other per-app resources. The napi surface is unchanged, so no backend/fleet/ code moves; the spec amendment also records the operator residuals (the stale hand-patched policy to delete post-repin, and egress admitting only DNS + 443, so placed cells cannot reach SMTP).

Verification

• npm run typecheck: clean.
• npm test: 147 passed, 18 skipped.
• spec-spine compile / index / lint --fail-on-warn: green, shards committed.

Coupling waiver

Spec-Drift-Waiver: the substantive change is spec 006 territory (its amendment is in this PR); package.json and package-lock.json (owned by 002-app-shell) change only by the one-line dependency pin moving to the published 0.2.0, the same shared-surface shape PR #42 waived for the original repoint.

[github-actions]

AI Code Review

Spec Coupling

Clean. The amendment is in specs/006-fleet/spec.md, both .derived/ shard hashes reflect a recompile (not hand-edited values), and the amendment entry in the registry JSON matches the spec text. No backend TS code moves, consistent with the claim that the napi surface is unchanged.

Bugs / Logic Errors

Orphaned 0.1.0 NetworkPolicies — migration gap. The 0.1.0 addon created a namespace-scoped fleet-allow-ingress-nginx per tenant namespace. The 0.2.0 removeApp deletes fleet-allow-ingress-<app> (the new per-app resource), not fleet-allow-ingress-nginx. Any tenant with a 0.1.0-placed app that is later removed via 0.2.0 will leave the old namespace-wide policy orphaned. The spec only documents the one hand-patched policy in the test tenant; multi-tenant environments accumulate these silently.

The spec should either add an operator run-book step (enumerate fleet-allow-ingress-nginx across namespaces and delete them after cutover) or, preferably, have 0.2.0's removeApp also attempt to delete the legacy name with tolerate-404 semantics.

Security

Transition window is intentionally more permissive — the spec correctly notes NetworkPolicies are additive during the handover period, but the above orphan scenario extends that permissive window indefinitely for tenants whose 0.1.0 apps are eventually re-placed or removed without a prior cleanup pass.

SMTP egress residual is pre-existing and correctly noted; no new surface opened here.

Performance

No concerns. This is a dependency pin bump with no hot-path changes.

---

Blocking: the migration gap for pre-existing 0.1.0 namespace-scoped policies needs resolution (automated cleanup in removeApp or an explicit operator run-book in the spec) before this is safe in a multi-tenant environment.

---

Automated review by Claude. Diff size: 85 lines.