fix(rivetkit): expose engine ray IDs on errors

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/actors

• #5602 feat(react): support connecting to actors by id in useActor
• #5600 fix(rivetkit): expose engine ray IDs on errors 👈
• #5601 fix(frontend): submit Vercel drain grace period
• main

Get stack: forklift get 5600
Push local edits: forklift submit
Merge when ready: forklift merge 5600

_{change kzmlwrll}

[claude]

Review

Traced the rayId field end-to-end: engine X-Rivet-Ray-Id header / WS close-reason suffix (guard-core/proxy_service.rs, err_to_close_frame) → RivetError/ActorError (actor/errors.ts) → HTTP/WS client handling (actor-handle.ts, actor-conn.ts, client/utils.ts) → NAPI bridge round-trip (BridgeRivetErrorContext, anyhow_to_bridge_rivet_error_payload) → back into JS-visible errors (registry/native.ts). The wiring is consistent at every hop I checked — argument order into checkForSchedulingError/#shouldRetrySchedulingError lines up, the sanitized-internal-error branch in deconstructError only drops rayId for genuinely non-structured errors that never had one, and the x-rivet-ray-id header name/format matches what api-builder::middleware and proxy_service.rs actually emit. Nice, well-scoped change.

Nits / suggestions (non-blocking):

• Test coverage: the new tests cover the HTTP-header path (rivet-error.test.ts) and the NAPI bridge round-trip (actor_factory.rs), but there's no test for parseWebSocketCloseReason's #rayId parsing (client/utils.ts) or for actorSchedulingError/checkForSchedulingError threading a rayId through. Those are the two other call sites this PR touches (actor-conn.ts WS-close path, actor-query.ts scheduling-error path) and are currently only exercised indirectly.
• checkForSchedulingError (actor-query.ts) uses the rayId from the triggering close/error event rather than the ray ID of the follow-up driver.getForId(...) call it makes to fetch actor.error details. That's a reasonable choice (correlates with the original failure), but might be worth a one-line comment since it's a bit non-obvious which request the surfaced ray ID actually corresponds to.
• rivetkit-napi/src/actor_context.rs's verify_inspector_auth_js sets ray_id: None — makes sense since inspector auth failures are local, not engine-originated, just flagging that it's the one BridgeRivetErrorContext construction site that doesn't populate it (intentional, not a bug).

No correctness, security, or performance issues found. Error sanitization boundaries (rivetkit-core as source of truth, TS-side deconstructError trusting canonical structured errors) are respected, and rayId is treated purely as a debugging/correlation field, never merged into or read from user-controlled metadata.