main.rs handles only SIGINT: as PID 1 a docker stop takes the 13s SIGKILL path

[plusky]

Summary

bugwarden installs only tokio::signal::ctrl_c(). On the HTTP transport it is the sole trigger of the graceful-shutdown future (crates/bugwarden/src/main.rs:177), and the stdio arm (service.waiting(), main.rs:141) installs no signal handling at all. As container PID 1 the process never gets SIGTERM's default terminate action, so docker stop / podman stop waits out the grace period and SIGKILLs: measured 13s + exit 137 bare vs 1s + exit 143 with --init. Found while shipping #106.

Why it matters

The image docs recommend --init / init: true (README.md:505-508), but Kubernetes has no equivalent, so k8s deployments always take the SIGKILL path. The abrupt kill also skips the graceful-shutdown arm that cancels the transport's cancellation token, so any orderly audit-sink shutdown goes with it.

Suggested direction

select! over ctrl_c() and a signal(SignalKind::terminate()) stream in the HTTP graceful-shutdown future (the same shape ruoqa-mcp's container commit added), and give the stdio arm the same escape hatch alongside service.waiting() so a stdio container as PID 1 terminates too.

Acceptance criteria

• As PID 1 without --init, docker stop / podman stop ends the process within the grace period with a graceful exit — anything but the 137 SIGKILL path — on both transports; re-measure the 13s/137 bare case from this issue and record the new numbers.
• Over HTTP, SIGTERM takes the same path as ctrl-c: the cancellation token is cancelled and axum's graceful shutdown runs, not an abrupt exit mid-request.
• README.md:505's "Use an init process" guidance is rewritten to describe the built-in handler (keeping --init as optional defense-in-depth), so the docs no longer present an init shim as the only correct deployment.