chore(container-runner): default stop grace to 10s

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #5539 feat(container-runner): report actors as crashed on unexpect …
• #5536 feat(container-runner): log unexpected platform SIGTERM as a …
• #5530 fix(rivetkit-core): cancel driver alarm before sqlite teardo …
• #5531 feat(container-runner): keep instance warm instead of self-e …
• #5533 chore(container-runner): default stop grace to 10s 👈
• #5528 fix(rivetkit): log and surface actor startup failures
• #5529 fix(rivetkit): treat empty actor input bytes as absent
• main

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

_{change xnpvnuup}

[claude]

Review: chore(container-runner): default stop grace to 10s

Small, self-contained change: lowers the default --stop-grace-secs / RIVET_STOP_GRACE_SECS (SIGTERM→SIGKILL grace period for the child process) from 25s to 10s in container-runner/src/main.rs.

Code quality

• Change is minimal and matches the CLAUDE.md guidance to avoid unrelated churn — just the default_value_t.
• Downstream usage (effective_stop_grace(), sleep_grace_period: stop_grace + Duration::from_secs(10)) is defined relative to stop_grace, so lowering the constant doesn't break any invariant. The sleep grace deadline still outlives the SIGTERM→SIGKILL window as documented in the comment near container-runner/src/main.rs:311.
• No test coverage exists for the CLI default itself, which is fine since this is a plain clap default rather than logic; not worth adding a test for.

Doc drift (found, worth fixing)

website/src/content/docs/deploy/container-runner.mdx:81 still documents the old default:

| `--stop-grace-secs` | `RIVET_STOP_GRACE_SECS` | `25` | ...

This should be updated to 10 in the same PR to match the new default, since it is user-facing reference documentation for this exact flag.

Other notes

• No security or performance concerns. This only affects how long a child process is given to exit gracefully before being force-killed, and 10s is still generous for most workloads.
• Worth double-checking with the author whether 10s is long enough for slower game-server shutdown sequences (e.g. flushing state or save-on-exit). This is a behavior change for existing deployments relying on the previous 25s default, not just for new installs.