test: CI job exercising NAPI-load-failure graceful degradation path

[sahrizvi]

Deferred from the v0.9.6 release review (Chaos Gremlin persona).

Context

v0.9.6 ships a fix (packages/opencode/src/altimate/native/dispatcher.ts) for a bug where a transient NAPI load failure during Dispatcher.call's lazy-registration hook would poison the whole bridge for the process lifetime — every subsequent Dispatcher.call (not just the failing one) threw No native handler for X, and the CLI had to be restarted.

The fix caches the in-flight registration promise so:

• Concurrent callers share one attempt
• On failure the cached promise is cleared so subsequent calls can retry
• On success _ensureRegistered is nulled so the hook does NOT re-run unnecessarily

Unit tests are in packages/opencode/test/skill/release-v0.9.6-adversarial.test.ts (4 cases). But those exercise the dispatcher-layer state machine only — they don't verify the real-world scenario: a customer platform where the @altimateai/altimate-core NAPI binding actually fails to load (older glibc, unusual arch, permission issues, cold-cache first invocation).

What to do

Add a CI job that:

1. Simulates a NAPI load failure on first Dispatcher.call (e.g. by pointing altimate-core.node at a missing/corrupted path)
2. Asserts the specific error surfaces to the caller (not a generic dispatcher error)
3. Asserts a subsequent Dispatcher.call re-attempts registration (i.e., the retry-after-failure invariant is preserved end-to-end, not just at the dispatcher unit-test level)
4. Runs on the platform matrix that most-likely hits real NAPI issues (linux-arm64, older Node runtime, etc.)

Belt-and-braces on the dispatcher retry fix. Not a repro of a customer report; prophylactic based on the release-review Gremlin lens.

Priority

P2 — the dispatcher unit tests cover the state machine; this CI job proves the state machine survives real-world NAPI failure modes.