Zitadel asks every user with an unverified address (registration, all
byoidc logins) for a code before the login finishes. Without an SMTP
provider the code was never sent (Errors.SMTPConfig.NotFound) and these
users were stuck. They now come from the send-only account id@lassul.us
on the mailserver, over TLS on mail.lassul.us:465.

lass.zitadel.smtp creates, updates and activates the instance's SMTP
provider. Zitadel 2.71 skips providers without a password, so the
password comes from passwordFile; a hash of the one Zitadel has is kept
in the state directory to update it when the file changes.

find_user tried the configured name as login name first. With
UserLoginMustBeDomain off (Zitadel's default and ours), anyone who
registers picks any free username, including lass@lassul.us or the
address of someone who has not registered yet, and got the grant meant
for that address. Only a verified address cannot be claimed this way.

HedgeDoc looks up users only by profileid, in one table with the GitHub
logins, whose profileid is the numeric GitHub user id. Without
userProfileIdAttr it is the username, which anyone chooses when
registering at id.lassul.us: a Zitadel user named after someone's GitHub
id logged in as that GitHub user, and a renamed or deleted username
handed its pad account to the next user taking the name. sub is the
Zitadel user id, which Zitadel generates and never reuses.

Existing Zitadel accounts in HedgeDoc are keyed by their login name and
need their profileid changed to the Zitadel user id.

B2 behind cache.lassul.us sometimes sends the headers and then no body;
when all retries for one .ls failed, `mount` gave up ("17 of 2892 store
paths without a listing") and the whole build substituted eagerly.

Now a path whose listing can't be fetched (or parsed, or built from its
NAR) is treated like a path not in the caches: it and everything
referring to it (from the references in db.dump) are dropped from
paths.json and db.dump before mounting, so they are neither served nor
registered and Nix substitutes them as usual; the rest stays lazy. Each
is logged once with its error, the counts go to no-listing.json, and
lazy-store.sh prints them in the "mounted" line (and counts the
registered paths after the mount). Narinfo fetch errors already ended up
in `missing` in `closure`.

16 of the 17 paths without a listing in CI run 39052697442 (neoprism)
failed with "missing field `entries`": cache.lassul.us writes empty
directories as {"type":"directory"}, e.g. 3k9vl6iwf58qy65wcjqccqykgzypm7va.ls
is {"version":1,"root":{"type":"directory"}}. harmonia-file-core's
Directory requires "entries", so since 207a89b5 that was an error; the
hand-walked parser before read a missing "entries" as empty. Fill it in
before deserializing. "size" of regular files is always written (also
for empty files).

The 17th, 9pczdaxss3xdmidr8cvgpw8ccn0agnhq.ls, is not a client bug: B2
itself (also queried directly, over HTTP/1.1) now and then answers 200
with Content-Length 78 and closes without sending a body byte. nginx
turns that into an HTTP/2 RST_STREAM INTERNAL_ERROR, which reqwest
reports as "error decoding response body". The same request succeeds
moments later; the existing retries cover it unless all six tries hit
a truncated response, as in that CI run.

closure uses harmonia-store-nar-info's parse_narinfo_txt and
harmonia-store-path's StorePath instead of our key/value narinfo map
and string splitting: the closure walk, referrers and missing sets are
keyed by StorePath (whose order is the string order, so paths.json and
db.dump come out the same), references, deriver, NarHash, NarSize,
URL, Compression and FileSize come from the parsed NarInfo. A narinfo
that doesn't parse counts as a failed fetch from that cache (try the
next one) instead of failing the whole run later on a missing field.
Roots that aren't store paths are an error.

paths.json, db.dump, narinfo/ and closure.json are byte-identical to
before for the closures of hello and git from cache.nixos.org.

The fetch test's path without a narinfo used an "e" hash, which isn't
nix32 and so no store path.