fix(rivetkit): surface native runtime load failures instead of masking them with wasm

[MasterPtato]

No description provided.

[MasterPtato]

Stack for rivet-dev/actors

• #5685 fix(universaldb): stop postgres commits from starving the co …
• #5670 fix(rivetkit): surface native runtime load failures instead … 👈
• #5667 fix(envoy-client): fail sent vfs sqlite requests on disconne …
• #5666 fix(rivetkit-core): report actor crashes as a sleep intent i …
• #5668 fix(envoy-client): ack start commands immediately instead of …
• main

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

_{change mputlvxy}

[claude]

Code Review (updated)

Re-reviewed after the latest push. The previous review covered native.ts and runtime.test.ts; this update adds a note on the newly-included engine/artifacts/openapi.json diff.

Summary

loadAutoRuntime previously swallowed the native-runtime load error whenever the wasm fallback succeeded, and if wasm also failed, the caller only ever saw the (usually irrelevant) wasm error. This PR:

• Captures the native error and logs it via logger().warn(...) before falling back to wasm, so a silently-skipped platform binding is no longer invisible when wasm happens to succeed.
• When both native and wasm fail, throws a single RivetError("config", "runtime_unavailable", ...) that includes both underlying error messages.

Correctness

Control flow is correct: nativeError is unconditionally assigned in the first catch before the second try runs, so there's no uninitialized-use path. The edge-like short-circuit and the explicit native/wasm request paths in loadConfiguredRuntime are untouched; this change is scoped to the auto fallback path only. No bugs found in the runtime-loading logic itself.

New since last review: engine/artifacts/openapi.json

This PR's diff now downgrades info.version from 2.4.0 to 2.3.14. Both main and this PR's stack base branch currently have 2.4.0, so this hunk isn't a byproduct of rebasing onto a newer base, it's the head branch regressing the value. This looks unrelated to the native/wasm runtime-loading fix and is very likely stale/unregenerated OpenAPI artifact state rather than an intentional change. Worth regenerating this artifact (or rebasing) before merge so main doesn't get its API version silently rolled back.

Style / conventions

• Structured logging (logger().warn({ msg, error: stringifyError(error) })) matches the existing pattern used elsewhere in this file.
• Comments are written as complete sentences per CLAUDE.md conventions.
• The new RivetError group/code (config/runtime_unavailable) is consistent with neighboring TS-only errors in the same file (unknown_runtime). Since this is a TS-native RivetError, not a Rust #[derive(RivetError)] type, no generated-artifact update is needed for it.

Test coverage

Good coverage in runtime.test.ts via an injectable RuntimeLoaders: native success, native failure with wasm fallback, both failing (asserts both error messages are present in the thrown error), and the edge-host path never touching native. These are deterministic unit tests with no module mocking, consistent with repo testing conventions.

Minor nits (non-blocking)

• The combined error message concatenates the two error strings with only a space separating "Native runtime: ..." and "Wasm runtime: ...". If stringifyError includes a stack trace (gated by the getLogErrorStack() debug flag), the boundary between the two sections becomes harder to read. A newline or semicolon separator would improve readability.
• This new error is constructed with public: true, so its message (including a stack trace when the debug flag is enabled) can propagate to a caller. This mirrors the existing sibling unknown_runtime error, so it's likely intentional, but this path runs at registry/server startup rather than per-request, so the practical exposure is limited to whoever is booting the registry.

Only blocking-ish item is the openapi.json version regression; the TypeScript logic itself looks correct and well-tested.