Config: deployment-managed env values (opt-in via DAPPS_ENV_MANAGED); derive the DAPPS callsign from the host node, probing for a free SSID

[M0LTE]

DAPPS now ships under pdn as a supervised app package, which made the first-start-only env seeding awkward: the host's app config should stay authoritative across restarts, and the owner shouldn't have to invent a callsign that the host already knows. Two behaviours, one PR — both completely inert for standalone installs.

1. Deployment-managed env values — opt-in via DAPPS_ENV_MANAGED=true (standalone flow untouched by default)

Review fix: the first cut re-applied set DAPPS_* vars unconditionally — a breaking change, since the shipped standalone flow (scripts/dapps.service → EnvironmentFile=/etc/dapps.env) keeps DAPPS_* permanently set and would have had every dashboard edit reverted on every restart.

DAPPS_ENV_MANAGED is a mode switch read each start (itself never stored):

• unset / false (the standalone default): byte-for-byte today's semantics. Env vars seed rows that don't exist yet (first start) and nothing else; the dashboard owns every value thereafter; no UI badges. The original ExistingRow_NotOverwrittenByEnv test asserting exactly this is restored, alongside a managed-mode counterpart — both contracts are pinned under their respective modes.

• true (the pdn supervised-app case): at every startup, any set DAPPS_<KEY> whose value differs from the stored row updates the row and logs:

  SystemOption {key} applied from environment (DAPPS_{KEY}) — this value is deployment-managed; dashboard edits will be overridden while the variable remains set

  UI: /Settings and /Setup badge any field whose env var is currently set with a "managed by environment" marker (tooltip names the variable) and render the control read-only/disabled. Saving unrelated fields still round-trips the managed values intact.

The repo-root pdn-app.yaml opts supervised deployments in (and its comment block explains both modes):

service:
  command: ./dapps
  environment:
    DAPPS_ENV_MANAGED: "true"             # opt in: env vars below are re-applied at every start
    DAPPS_NODE_BEARER: rhpv2
    # …

docs/configure.md gets the same note; its documented standalone first-start-only contract is unchanged.

The seed call in Program.cs now gets a bootstrap console logger — previously it passed no logger, so none of the seeding decisions were visible in the journal.

2. Callsign derived from the host node — now probing for a free SSID

"as a rule I would generally expect DAPPS to reside at an SSID of the node callsign"
"Any way for the setup flow to check for free/taken SSIDs, and pick one?"

When the stored callsign is absent or the N0CALL placeholder and the pdn host injects PDN_NODE_CALLSIGN, DAPPS derives its identity as <base-of-node-callsign>-<Ssid> (Ssid is a new seeded option, default 7, env-overridable as DAPPS_SSID). This derivation is deliberately not gated on DAPPS_ENV_MANAGED — standalone installs have no PDN_NODE_CALLSIGN, so it cannot affect them.

And instead of blindly trusting -7, the derivation is now confirmed over RHPv2 itself. pdn answers a listen on an already-claimed callsign — including the node's own — with errCode 9 "Duplicate socket", deterministically (its docs/rhp2-server.md deviation D5). So:

• DbStartup records each derivation in a DerivedCallsignPending row. While that marker still matches the callsign in use (and no explicit DAPPS_CALLSIGN is set), Rhpv2InboundService treats a 9 on bind+listen as "taken" and walks the candidates: start+1 … 15, then 1 … start−1, skipping 0 and the SSID the node itself uses (parsed off PDN_NODE_CALLSIGN). First successful listen wins.
• The winner is persisted as the stored callsign (one log line: derived callsign M9YYY-8 — -7 was taken on the node) and the marker is cleared, so the identity is stable on every later start — a persisted, confirmed callsign never walks again.
• An explicitly configured callsign (env, dashboard, or already-confirmed) never walks: a 9 logs the refusal and keeps the existing retry/reconnect cadence.
• All candidates taken → log loudly and revert to setup-required mode (no spinning against the node); the next restart re-derives and probes again.
• Against a server that answers duplicate listens Ok (live XRouter does), the walk simply never triggers — fine, since derivation only runs under pdn supervision.

Precedence (highest first): explicit DAPPS_CALLSIGN env → real stored callsign (dashboard-configured / probe-confirmed) → derivation+probe → N0CALL placeholder (standalone, setup-required mode as today). /Setup still prefills its callsign field with the derived value in the rare case the bearer step renders while PDN_NODE_CALLSIGN is present.

⚠️ Tom's call — proposed default DAPPS_SSID=7: there is no packet-wide DAPPS SSID convention yet, so this PR proposes one. -7 matches the M0LTE-7 identity the pdn acceptance testing used. It's a one-line constant (DbStartup.DefaultSsid) if you want a different number — and with the probe-walk, a collision at -7 now resolves itself anyway.

Release asset

The release job now attaches the repo-root pdn-app.yaml (#148) next to the binaries, with its informational version: stamped to the release tag, so the pdn build fetches manifest + binary from the same release instead of carrying an interim copy.

Tests

dapps.core.tests: 674 passed, 0 failed (branch baseline: 660/0; pre-PR baseline: 651/0). The PR's flipped ExistingRow_… test is un-flipped — the restored standalone contract plus a DAPPS_ENV_MANAGED=true counterpart, =false-same-as-unset, and badge gating. New DbStartupTests cover the pending-marker lifecycle (set on derivation, survives unconfirmed restarts, cleared by dashboard/env-pinned identities, confirm/abandon round-trips). New Rhpv2SsidProbeWalkTests drive the walk against MockRhpServer playing pdn's D5 role, through the real SystemOptionsStore persist→reload path: walk-on-9 picks the next free SSID + persists + is stable across restart; an explicit callsign never walks; non-9 errors never walk; all-taken walks in the exact documented order then reverts to setup-required; plus the candidate-order unit test.

Also verified live earlier on this branch: fresh start under pdn-style env derives and seeds correctly; a restart re-applies an env var over a dashboard edit (with the log line above) while leaving a dashboard-pinned real callsign alone — that behaviour now sits behind DAPPS_ENV_MANAGED=true.

🤖 Generated with Claude Code