ipx-directory: the directory of public podcasts ipx servers share (#204)

A new crate and service, crates/directory, live at ipx-dir.sdf1.net. ipx
servers send the public feeds their people subscribe to (POST /v1/snapshot,
replacing what that token sent before); the directory fetches each feed's
title, artwork, category, description and latest twenty items every six
hours with ipx-feed, and lists them A to Z and by subscribers summed over
every server. It holds metadata only, never a file or a file's address.

Tokens are in its config file as SHA-256 hashes, each ro, rw or rwa, and
the file is read again within a minute of a change, so adding and revoking
one is an edit and nothing else; a revoked token takes its server's counts.
At first they were to come from environment variables, which would have
meant recreating the container to add one. A file that does not load keeps
the tokens as they were.

Every address sent is checked with ipx_feed::url_looks_private, the check
ipx makes before sending, so one server's miss does not publish a paid feed
to every other; an rwa token can remove and block what both miss.

Deployed: ipx-directory in the ipx Arcane project, database ipx_directory
(its own login) on the databases project's Postgres, which db-backup
already covers, and a tunnel route with no Access in front. The store's
tests run on Postgres as well as SQLite when IPX_TEST_DATABASE_URL is set.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.claude/skills/ipx-prod-check/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ipx-prod-check
-description: Look for problems in production ipx (the iPX container on Tower) from its logs in Loki, its traces in Tempo and its metrics in Prometheus, and file what is found as Gitea issues. Use when asked to check on production, look for issues or errors in ipx, see why something is slow or failing in production, review the logs, or investigate a report about the live site.
+description: Look for problems in production ipx (the iPX and ipx-directory containers on Tower) from its logs in Loki, its traces in Tempo and its metrics in Prometheus, and file what is found as Gitea issues. Use when asked to check on production, look for issues or errors in ipx, see why something is slow or failing in production, review the logs, or investigate a report about the live site.
 ---
 
 # Checking production ipx
@@ -205,6 +205,26 @@ docker ps --filter name=iPX --format '{{.Status}}'
 docker logs --since 10m iPX 2>&1 | tail -5
 ```
 
+## The directory
+
+`ipx-directory`, in the same Arcane project, is the directory of public podcasts ipx servers share
+(docs/directory.md), public at `ipx-dir.sdf1.net`. It logs JSON to Loki under
+`{container="ipx-directory"}`: a line a request, with the `token`'s name and never the token, and
+a line for each snapshot and each feed check that failed.
+
+```sh
+docker ps --filter name=ipx-directory --format '{{.Status}}'
+$Q metric 'sum by (status, token) (count_over_time({container="ipx-directory"} |= "ipx_directory::http" | json | __error__="" [$range]))'
+$Q logs '{container="ipx-directory"} | json | level=~"WARN|ERROR"'
+$Q logs '{container="ipx-directory"} |= "\"message\":\"snapshot\""' 7d
+```
+
+A burst of 401s with an empty `token` is someone without a token trying it, which is expected now
+and then from a public address; a steady stream is worth an issue, since Cloudflare can rate-limit
+it. A snapshot whose `refused_private` is not 0 means an ipx server tried to send a feed that looks
+private: find which in that server's log, since the directory refuses it but the sender should not
+have sent it. Many `feed check failed` lines for one feed are the publisher's, not the directory's.
+
 `docker logs` and `docker exec iPX ipx ...` are fine. Do not query production's Postgres
 directly: ask the user if a question needs the database.