20260922 - Let an owner claim their node from the configuration page

[Purple10101]

Half of one feature, across two repos. The other half is
offworldlabs/retina-telemetry#21, which reads what this writes and talks to the
server. This is safe on its own: with today's telemetry the section simply
reads "Not reported yet", and nothing else on the page changes.

What this is

Node ingest v1.3.0 added the claim: a node offers the address that owns it, the
server mails that address a link, and opening it binds the node to the account
behind it. Nothing on a node knew such an address, so nothing collected one.
This is that collection, as a section of its own between How we reach you and
Cloud services.

A section rather than a row inside the contact block, and the distance is the
point. The two boxes look identical and are not. The contact email answers
"whom do we ring about this node", is optional throughout and grants nobody
anything. This one answers "who owns it", and a wrong value mails a stranger a
link that hands them somebody's node. Separate files, and nothing anywhere
copies one into the other.

Two buttons, because one would not work

Save records the address, and a changed address is what makes retina-telemetry
offer it. That offer is the call that mails, so saving is never a second way to
ask for a link.

Send again exists because of something found by running the claim against
production rather than by reading the spec. Declining a link returns the node
to unclaimed but leaves the address on file, and re-offering an address the
node already holds is accepted, changes nothing and mails nothing. So a node
can sit unclaimed with an address against it and no amount of saving will move
it. POST /nodes/claim/resend is the only way out, and the section says so in
as many words when it sees that state.

What this side deliberately does not know

Which of the two calls to make. The file carries the address and, when the
owner presses send again, a timestamp. retina-telemetry decides the verb,
because it is the only thing here that talks to the server and knows where the
claim actually stands. A rule implemented on both sides is one that eventually
disagrees with itself.

The timestamp is also how the ask reaches a service that binds no ports and
cannot be called: nothing pushes to retina-telemetry, so an event has to be
left somewhere for it to find.

What it shows, and what it refuses to guess

State comes from retina-telemetry's status document. When that is absent or
stale the section says it cannot tell, rather than defaulting to "not claimed":
telling an owner nobody owns their node is a claim in itself, and this page is
in no position to make it. An unrecognised state is shown as itself, so a value
from a later server reaches the owner rather than disappearing. A bounced
address gets its own line, because sending again cannot help until the address
changes.

Evidence

942 tests pass, ruff clean, and the dead-code hook passes.

CI cannot cover the thing most likely to break this, though: requirements.txt
leaves pydantic unpinned so CI installs v2, while every node runs v1.
So it was also run on a real node under pydantic 1.10.4, where all three
validation branches were exercised: the over-length address the model catches,
the malformed one the route catches, and a resend with no address. All three
return clean field errors.

On that node the whole chain ran against a mock server, so nothing was mailed:
saving wrote the file, telemetry offered it, and the page came back with "Link
sent. Waiting for ... to open it." The declined state was driven too, and
confirmed that Save then sends nothing while Send again produces exactly one
resend.

🤖 Generated with Claude Code