#1605 serve telemetry identity warnings are diagnostic but not actionable — say how to fix them

Problem

swamp serve now logs the telemetry identity it resolved at startup (added in swamp-club/swamp#2117, v20260811.162323.0-sha.e1a01920):

Telemetry: flushing to https://telemetry.swamp-club.com as <uuid> (authenticated: false)
Telemetry: no user or repo identity resolved — scheduled runs will not be reported
Telemetry: disabled for this process

These tell an operator what happened but not what to do about it, and the failure they exist to surface is one where the operator has no other signal. distinct_id comes from a HOME-relative identity file, so a daemon running under a different HOME than the operator's shell — a system unit, a container, a User= directive — resolves a different identity and credits an account nobody is watching. On the site that is indistinguishable from reporting nothing at all, which is exactly the confusion #1590 produced.

The authenticated: false line has the same gap: it is the difference between events attributed to a user account and events attributed to an anonymous id, and the operator is not told that swamp auth login is what changes it.

Proposed

Make each message carry its remedy:

• No identity resolved — name the path that was checked and what creates it, so the HOME mismatch is visible rather than inferred.
• authenticated: false — point at swamp auth login; without it, runs are reported but not attributed to the account the operator is looking at.
• Consider pointing at swamp whoami as the one command that answers "which identity am I reporting as", since that is the actual question behind all three lines.

The messages already follow the established Category: detail pattern used by Datastore:, Vault:, and Mode:, so this is wording, not structure.

Alternatives

Leave as is — the lines are already a large improvement over the previous silence, and an operator who reads them knows to investigate. The counter-argument is that the population most affected (daemon under a different HOME) is precisely the one least likely to be reading startup logs closely, and a bare uuid gives them nothing to search for.

Source

CLI UX review on swamp-club/swamp#2117, non-blocking suggestion. Related: #1591, #1590.