docs: add production deployment guide

[Justinabox]

Summary

• Adds a production Raspberry Pi + systemd deployment guide for packaged callstack serve.
• Documents locked-down local config/state paths, service hardening, executable-path discovery, loopback-first network posture, and private-safe health/metrics smoke checks.
• Adds regression coverage for deployment guidance, functional non-echoed authentication headers, private-material checks, and no example webhook destination URLs.
• Updates README and ROADMAP to link and classify the shipped operator-DX guidance.

Closes #161.

Verification

• git diff --check
• PYTHONPATH=. uv run --no-project --with pytest --with pytest-asyncio --with pytest-aiohttp --with pyserial-asyncio --with aiosqlite pytest tests/test_packaging_metadata.py tests/test_cli.py tests/test_metrics.py -q — 59 passed
• PYTHONPATH=. uv run --no-project --with pytest --with pytest-asyncio --with pytest-aiohttp --with pyserial-asyncio --with aiosqlite pytest tests/ -q — 1007 passed

Risks

Documentation-only change. It does not create, enable, or modify a systemd service, access modem hardware, or alter Callstack runtime/authentication behavior. Operators must adapt documented local paths and service account policy to their deployment.

[Justinabox]

Release review classification: needs-human. This introduces or documents a product-level capability/data-retention/deployment decision beyond a narrow behavior-preserving fix. It will not be auto-merged in this lane. Please retain the branch for Korgo’s product/operational decision, then request a focused follow-up review against current main.

[Justinabox]

Release review: needs-human. This is a broad production-deployment guide that recommends service/account/filesystem/network/auth operational policy. It does not change runtime code, but publication creates a production-facing operator contract. Please obtain Korgo's deployment-owner approval after a deliberate review of the documented systemd hardening, path ownership, authentication posture, and packaging/install commands. It is not being merged autonomously in this lane.

[Justinabox]

Release-lane classification: needs-human.

The production deployment guide makes operator-facing systemd, filesystem-permission, and authentication-posture recommendations. Even though code impact is documentation-only, its production guidance requires explicit owner review before landing. No merge action taken in this lane.

[Justinabox]

Release-lane classification: needs human decision.

This introduces or documents a material product/operational behavior. It requires Korgo's decision on public semantics, retention/operations expectations, and rollout scope before an autonomous merge; local test success alone is not authorization to land it.

[Justinabox]

Release classification: needs-human.

Production deployment guidance is an operational/security commitment. It needs Korgo’s approval of the documented deployment model, authentication/default-exposure guidance, and support scope before autonomous landing. Keep it draft; after a decision, rebase/repackage over current main and run the prescribed gates.

[Justinabox]

Release review: needs-fix. The deployment smoke snippet constructs Authorization: *** <key> instead of the runtime-required Authorization: Bearer <key>, so it cannot authenticate as documented. Correct the non-echoing header construction, add/adjust a source-derived regression, rebase on current origin/main, and rerun docs/required gates.

[Justinabox]

Release review remains needs-human for this production/operator-facing deployment contract. It also needs the following corrections before an approval pass:

1. The documented editable install (pip install -e) conflicts with ProtectHome=yes when the checkout/venv is under a home directory: the unit cannot read the editable source path. Document a non-editable production install in a system-readable location (or explicitly mount/document the source path), and add a regression that covers the documented layout rather than only checking directive strings.
2. The non-loopback section must say Callstack itself always needs --api-key-file outside the development-only loopback override. A reverse proxy may authenticate clients, but it must still preserve/provide a bearer credential to Callstack; there is no trusted-proxy auth mode in the current CLI policy.
3. Treat /etc/callstack/callstack.env as secret-bearing whenever it contains a SIM-PIN variable, alongside the API-key file.

Read-only three-way merge check against current origin/main was clean. Gates on the PR head: git diff --check passed; required full pytest gate passed (1007); python -m build passed (wheel + sdist). No hosted CI checks are configured for this head.