v0.17.0 — PR preview URLs reach the API; agent status stops guessing

A PR preview's URL now reaches the control API, and piper agent status reports what the daemon actually loaded instead of guessing.

⚠️ Manual upgrade step — agent DB

deployments gained a hostname column. Pre-1.0 there are no migrations, and CREATE TABLE IF NOT EXISTS does not add columns to an existing table — so on an untouched DB, GET /v1/apps/{name}/deployments fails with no such column: hostname. That breaks piper deploy's progress follow, the TUI's deployment list, and the dashboard's app view. Deploys themselves keep working.

Add the column — one line, no data loss. Under the shipped systemd unit the DB is /var/lib/piper/piper.db; otherwise it is ~/.piper/piperd/piper.db, or wherever PIPER_DATA_DIR points. piper agent status prints the effective path (accurately, as of this release):

sudo systemctl stop piperd
sudo sqlite3 /var/lib/piper/piper.db "ALTER TABLE deployments ADD COLUMN hostname TEXT NOT NULL DEFAULT ''"
sudo systemctl start piperd

macOS/Homebrew: brew services stop piper, run the same sqlite3 line against ~/.piper/piperd/piper.db (no sudo), then brew services start piper. On Debian/Ubuntu/Pi install sqlite3 first if it is missing (sudo apt install sqlite3).

Existing deployment rows get an empty hostname — cosmetic, since previews re-record theirs on the next tunnel reconnect. Replacing the DB outright also works but costs you your apps, env vars, custom domains, tokens and enrollment, so prefer the ALTER.

Relays are unaffected: nothing in this release touches the relay schema or the agent↔relay wire protocol, so there is no relay-before-agents ordering to respect.

Upgrade as usual: brew upgrade piper && brew services restart piper, or sudo apt update && sudo apt install piperd piper.

What's new

• A preview's URL is now in the API (#479). Preview hostnames are keyed (agent, app, pr) and apps.hostname holds production's alone, so a preview's URL previously existed only on the PR's GitHub deployment — a client could tell a deployment was a preview but had nothing to link to. It is now persisted on the deployment row and served from GET /v1/apps/{name}/deployments as Hostname, and refreshed on tunnel reconnect so a relay-side rename can't leave a dead URL in the API. This is the preview counterpart of #137.
• piper agent status stops guessing (#477). Listen addresses and data dir came from /proc/<pid>/environ, which is root-only for a system piperd — so a non-root status printed the built-in defaults as fact and env-file overrides were invisible. It now prefers the daemon's own GET /v1/version self-report, falls back to /proc where readable, and marks the last resort (assumed — the agent did not report) rather than posing as truth.

Known issues shipped open

Carried over, none regressed by this release: piper agent status compares against the PATH-resolved binary rather than the unit's ExecStart (#472); piper login reruns the device flow even with a valid saved credential (#473); the relay learns App installations only from webhooks, so an already-installed App may need a suspend/unsuspend to re-link (#470, #471); relay-deploy runbook corrections (#474); prerelease-only deb checksum filename mismatches (#475).

Dashboard rendering of the new preview link is separate work in the dashboard repo and is not in this release — the data is available, the UI does not surface it yet.