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

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #5548 feat(container-runner): log version and git sha at actor sta …
• #5549 feat(container-runner): setup instance memory and cpu usage …
• #5546 fix(rivetkit): keep actor event loop alive through shutdown …
• #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

Small, focused change: lowers --stop-grace-secs / RIVET_STOP_GRACE_SECS default from 25 to 10 in container-runner/src/main.rs. The change itself is safe -- sleep_grace_period is derived from stop_grace dynamically (stop_grace + Duration::from_secs(10) in async_main), so nothing else hardcodes the old value in code.

Issue: stale docs reference the old default (25)

Three places still document 25 as the default and will now be wrong:

• website/src/content/docs/deploy/container-runner.mdx:81
• docs/docs/deploy/container-runner.mdx:81
• container-runner/examples/unity-demo/Dockerfile:32 (comment: RIVET_STOP_GRACE_SECS ... (default 25))

Per this repo's docs-sync convention, please update these alongside the code default so they don't drift. I checked the rest of the stack (#5531 downstream, and the other container-runner PRs in this chain) and did not see a follow-up that fixes these, so they look like they would stay stale after merge.

Minor

• No test coverage change, but this is a default_value_t tweak on a CLI arg, not really testable beyond a smoke test, so that is fine as-is.
• A one-line PR description noting why 10s was chosen over 25s (e.g. faster shutdowns / fitting inside a platform kill window) would help future readers, especially since the Dockerfile comment references the sleep_grace_period cap logic tied to this value.

Overall: safe change, just needs the doc/comment sync.