fix(website): resolve sign-in by the asset that signed, not only the BTC hash

website_verify resolved every asset through get_user_by_pubkey_hash, but
users.pubkey_hash only ever holds the BTC key's hash. On this backend only BTC
could ever resolve; ltc, xmr, wow and grin were structurally impossible, and the
failure was indistinguishable from an unregistered user, so the page told people
to register with an extension they already had.

That did not surface while smirk.cash pointed at the legacy backend, which
resolves by asset key against its own database. It becomes the whole bug the
moment the site is repointed here, so it has to land with that change, not after.

get_user_by_pubkey_hash stays as the BTC fallback: of 95 users on this backend,
84 arrived through migrate-legacy, which imported identity without keys, and
would otherwise stop resolving entirely.

The rejection message is unchanged and still says nothing about whether an
account exists.

.env.example

@@ -347,8 +347,15 @@ PUBLIC_EXPOSE_VERSION=false
 PUBLIC_EXPOSE_CHAINS=false
 PUBLIC_EXPOSE_PRICE_FEED=false
 PUBLIC_EXPOSE_UPTIME=false
+# Aggregate public stats on `GET /api/v1/server-info` (requires the landing
+# surface above). Currently one number: how many users hold a handle on this
+# instance, rounded down to a coarse bucket and held still for CACHE_HOURS so
+# repeated polling cannot difference out individual registrations.
 PUBLIC_STATS_ENABLED=false
 PUBLIC_STATS_CACHE_HOURS=24
+# k-anonymity floor. Below this many handles the block says only that some
+# exist, never how many.
+PUBLIC_STATS_MIN_USERS=20
 
 # ── Data retention / erasure ──────────────────────────────────────────────
 # When ERASURE_ENABLED=true, self-service erasure needs ADMIN_KEY_INTEGRITY_SECRET