feat(rivetkit): isolate managed engine storage by port

[NathanFlurry]

No description provided.

[NathanFlurry]

Stack for rivet-dev/rivet

• #5512 fix(actors): surface unregistered actor startup errors
• #5514 fix(rivetkit): protect local serverless handler ownership
• #5513 fix(rivetkit): reject conflicting local envoy connections
• #5510 feat(rivetkit): isolate managed engine storage by port 👈
• #5511 feat(engine-process): support caller-defined engine instance …
• main

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

_{change qluuutut}

[claude]

Review

Solid, well-scoped change (note: this replaces my earlier review, which was written against a prior version of this PR that included a welcome-banner "Storage" line and a managed_storage_root() helper -- those have since been dropped from the diff).

The core logic (engine_resolver_config / managed_engine_instance_path in rivetkit-rust/packages/rivetkit-core/src/registry/mod.rs) correctly mirrors engine_instance_path/engine_db_path in rivetkit-rust/packages/engine-process/src/lib.rs: when instance_path is None the legacy shared var/engine path is used (matches the default port 6420), and when set it produces var/engine/instances/{port}/db. The port computed for the isolation decision (config.engine_port or parsed from the endpoint) correctly matches the port engine_env actually binds to, so there is no drift between what is isolated and what port the engine really listens on. It is properly feature-gated behind native-runtime, which is a default feature, so the new unit test actually runs in CI.

A couple of things worth a look:

1. No direct test for the actual decision logic. The new test (non_default_ports_get_isolated_managed_instance_paths) only covers the pure path-join helper managed_engine_instance_path. engine_resolver_config -- the function that decides whether to isolate, based on config.engine_port vs. the endpoint-parsed port, and the != 6420 threshold -- has no direct test. Given this is the function that actually encodes the port/isolation invariant the PR depends on, it would be worth a couple of cheap table tests: engine_port explicitly 6420 (no isolation), engine_port set to a non-default value (isolation), engine_port: None with a non-default endpoint port (isolation via URL parsing), and engine_port: None with the default endpoint port (no isolation).

2. 6420 is a bare literal, now duplicated a third time. if port != 6420 in registry/mod.rs joins the existing engine_port.unwrap_or(6420) in registry/envoy_callbacks.rs:155. Since this literal now encodes a real invariant (paths above and below it diverge structurally, not just a fallback default), a shared const DEFAULT_ENGINE_PORT: u16 = 6420 would avoid the two call sites silently drifting if the default ever changes.

Minor: the TS #printWelcome banner rename ("serverful" -> "envoy") is unrelated to the storage-isolation feature in the commit title/description and introduces a small terminology split: runtime/index.ts's StartKind type and the Rust record_rivetkit_info(..., "serverful", ...) metrics label still say "serverful", while the printed welcome banner now says Mode: envoy. Not a bug (different type, nothing breaks), but worth confirming this rename is intentional scope for this PR rather than a leftover from an earlier revision, and whether StartKind/the metrics label should follow along for consistency.

No security or performance concerns -- this only affects local dev-managed engine storage layout under ~/.rivetkit, is gated behind native-runtime/local-loopback checks, and no user-facing/wire protocol changed.