M33: the network is on by default

Decision

The project lead decided that the SuckerPot network should be easy to join and easy to leave, and that joining should be what a new install does unless the owner says no. The feature is now unlocked by default. Joining stays an explicit act with a consent screen.

What changed

Area	Before	Now
NETWORK_ENABLED	Default false (ingest, API, compose)	Default true. It only unlocks joining. false still switches everything off
Full installer	No network question	After the other questions it shows the consent screen and asks Join the SuckerPot network? [Y/n]. The default is yes. --yes is a yes. --no-network declines and writes nothing
NETWORK_CONSENT	Written by the participant install only	Also written by the full install on a yes (five required items, version v2), with a random pseudonym
Ingest auto-join	Participant mode only	Both modes. It reads a valid consent record and requests membership once
Rejoin	Not covered by a test	Tested end to end: after a completed leave the dashboard join works and enrols a fresh identity
GET /setup/ports	One GROUP BY sensor over 24 hours of events	One indexed max(ts) per known sensor (the same fix for Settings and the setup checklist)

Invariants that are kept

• An explicit question, never a silent join. The installer shows what is shared and asks. The dashboard join still needs the password again and all five consents.
• No join on upgrade. An install without a NETWORK_CONSENT record stays out. Unlocking the feature by default does not create a membership.
• VPN only in full mode. The full-mode worker sends through the VPN egress gate only. hubproxy and EGRESS_MODE=direct remain participant-only. An accepted join in a full install waits (egress_closed) until a VPN is configured.
• The self-address lock. Nothing is submitted until the own public address is known. The full installer does not set SELF_TERMS_AUTO_CONFIRM.
• Leave is sticky. A leave stores left_day, and a restart or an update never joins again from the record in .env. The record is also spent after 7 days (consent_stale), so a restored database cannot undo a leave; just set NETWORK_CONSENT= clears it.
• Upgrade. env-migrate.sh pins NETWORK_ENABLED=false on an install without the NETWORK_DEFAULT_PINNED marker that has no active NETWORK_ENABLED line, so the new default never resumes a network someone switched off. Joining again is a new decision made in the dashboard (or participant.sh join).
• NETWORK_ENABLED=false keeps the old behaviour: no worker traffic, the API refuses a join.

Guardrails changed

• scripts/guardrails/tests/fixtures/owner_baseline.json and the compose default now read NETWORK_ENABLED:-true.
• test_a_full_install_writes_no_participant_settings no longer lists NETWORK_CONSENT as forbidden in a full install, because a yes now writes it. It still forbids the participant-only settings (stack mode, hubproxy, direct egress, auto-update, self-terms auto-confirm), and new tests pin the full-mode record to the five required items.
• The installer test sandbox copies scripts/lib/pseudonym.sh and the word list, which a full install now needs.

Not done here

The README, the website and the web UI still describe the network as opt-in. The dashboard join dialog must keep showing the five items and sending the confirmation.