fix: attach context to startup permission errors (#62)

[thedancingdeveloper]

Summary

Two fixes for #62:

1. Startup errors now carry context. Two ?-propagated io::Errors had no .context(), so a permission failure crashed the process with nothing but a bare Permission denied (os error 13) — no path, no address, no hint. This matches the reporter's log verbatim.

• crates/nzb-web/src/startup.rs — create_dir_all for data_dir/incomplete_dir/complete_dir now goes through a create_data_dir() helper that wraps the error with the failing path and a Docker-ownership hint (mirrors the existing pattern in AppConfig::load/save).
• apps/rustnzb/src/server.rs — TcpListener::bind in serve() now wraps the error with the bind address.

Reproduced locally before the fix: pointing data_dir at a path under a chmod 000 parent produced the anyhow {:?} output Permission denied (os error 13) — nothing else — confirming this is a real, reachable source of the reported crash text. (The other candidate, a privileged-port bind failure, is a secondary/unlikely cause here since the Docker image hardcoded --port 9090 — see below.)

2. RUSTNZB_PORT was dead in the Docker image. svc-rustnzb/run always passed --port 9090 explicitly, and clap gives an explicit CLI flag precedence over its env fallback, so RUSTNZB_PORT (and config.toml's general.port) were silently unconfigurable in Docker despite being documented as a general env var override. Removed the hardcoded flag so the env var (and config file) actually take effect; default when neither is set is unchanged (still 9090, matching the Dockerfile's EXPOSE and config.rs's default). Since the image's EXPOSE stays static at build time, documented that overriding RUSTNZB_PORT still needs a matching host-side port remap (-p host:$RUSTNZB_PORT).

This is a diagnosability + configuration fix, not a fix for the reporter's underlying Synology permission/ACL problem — it turns an untraceable bare crash into an actionable error, and makes the documented RUSTNZB_PORT behavior actually true. Still waiting on the reporter for their config values and full log to confirm which exact path fired; see issue comment: #62 (comment)

Test plan

• cargo test -p nzb-web --lib — unit tests for create_data_dir: positive (nested dir creation succeeds) and negative (non-writable parent produces context-bearing error, #[cfg(unix)])
• cargo test -p nzb-web --test startup_directory_errors — integration tests: positive (custom, non-default incomplete/complete/data dirs succeed), negative (regression guard asserting the error is not the bare Permission denied (os error 13) text from "Permission denied" in Synology container manager #62, and does contain the failing path)
• cargo test -p rustnzb --test server_bind_error_test — integration tests: positive (bind to a free port succeeds), negative (bind to an already-occupied address fails with context naming the address)
• cargo test -p rustnzb --bin rustnzb — regression tests locking in clap's --port/RUSTNZB_PORT precedence (env used when no flag; flag wins when both given; None when neither), so a future entrypoint change can't silently reintroduce the hardcoding bug
• Full existing suites green: cargo test -p nzb-web --tests (69 unit + all integration), cargo test -p rustnzb --tests (all e2e/integration)
• cargo fmt --check / cargo clippy --all-targets -- -D warnings clean on both crates

References #62.

🤖 Generated with Claude Code