fix(hub): a desktop solve reports no hostname at all, not "meshbay"

Registering from the native client failed with `captcha_failed` while the
checkbox was green — a worse symptom than the one being fixed, because the
widget now looked fine and only the hub's own log said otherwise:

    captcha solved on an unexpected host ''; allowed: ['localhost', 'meshbay', 'meshbay.org']

The previous commit assumed Google would report the host component of the
origin, so `app://meshbay` would come back as `meshbay` and could sit in
`allowed_hosts`. It does not. A solve Google cannot attribute to a domain
reports an **empty** hostname, and no allowlist entry can match that. An empty
entry is not the answer either: a blank in a TOML list is a typo far more
often than an intention, and `load_config` drops blanks for that reason —
`captcha.allow_unattributed_host` is a named flag instead, so the trade is
stated where it is made.

What it admits, plainly: every non-web client, not only ours. A file:// page
or somebody else's Electron application look identical from here. That is the
same bar the client's own origin would have been — main.js already records
that `app://meshbay` is not a credential — and it is a bar: the captcha still
has to be solved, per token, in something that can render it. What is given up
is the origin restriction for non-web clients, not the captcha. Off by
default, and a hub without the desktop client should leave it off.

The refusal now names which of the two it is, since they need different
answers: an unexpected host names the host, an unattributed one says to set
the flag.

docs/captcha.md §6 said `meshbay` was the value and told operators to add it;
it now records what was measured and why the guess was wrong. The packaged
example config carries the flag with the same warning.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML

1 files changed, 13 insertions, 3 deletions

diff --git a/packaging/conf/hub.toml.example b/packaging/conf/hub.toml.example
index d647707..7f5ac8f 100644
--- a/packaging/conf/hub.toml.example
+++ b/packaging/conf/hub.toml.example
@@ -66,8 +66,18 @@ secret_key = ""
 # and is served from `app://meshbay`, so the hostname Google sees is not this
 # hub's and never can be; with the console check on, the widget shows
 # "Invalid domain for site key" and nothing client-side reaches that decision.
-# Add the client's own host only if you distribute it — it is the weak entry,
-# since any Electron application can claim the same scheme and host.
 #
-#   allowed_hosts = ["hub.example.org", "localhost", "meshbay"]
+#   allowed_hosts = ["hub.example.org", "localhost"]
 allowed_hosts = []
+
+# A solve Google cannot attribute to a domain reports an *empty* hostname —
+# the desktop client's `app://` origin does, and so does any other non-web
+# client. No `allowed_hosts` entry matches that, hence a flag rather than a
+# blank list entry.
+#
+# What it admits is every non-web client, not only this project's: a file://
+# page or somebody else's Electron application look identical from here. The
+# captcha still has to be solved per token; what is given up is the origin
+# restriction for those clients. Leave it off unless you ship the desktop
+# client. See docs/captcha.md §6.
+allow_unattributed_host = false