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

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.