web serve: --auth is the only credential route, and it leaks the password via the process list

[TbusOS]

Summary

engram web serve correctly refuses a non-loopback bind without auth
(web/server.py:101, DESIGN §7.4). But --auth USER:PASS is currently the only way
to supply credentials — and on a multi-user host the command line is world-readable,
so the password is visible to every other account on the machine.

Why this matters

The hard refusal exists because binding a non-loopback address exposes the store to
the local network. That reasoning is right. The problem is that the only credential
route defeats it: on any Linux host where /proc is mounted without hidepid, a
plain ps -eo args shows the full command line of every process, regardless of owner.

Observed on a shared development server with roughly ten accounts:

$ ps -eo args | grep 'engram web'
... engram web serve --no-open --host 0.0.0.0 --port 8793 --auth demo:PLACEHOLDER-NOT-A-SECRET
                                                                 ^^^^ readable by every account

$ mount | grep ' /proc '
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)      # no hidepid

The password lands in shell history too.

So the security control and safe practice contradict each other: the tool insists on
auth for a non-loopback bind, then offers only a route that publishes the secret to
everyone on the box. A user who follows the error message's instruction verbatim ends
up worse off than they expect.

Proposal

Keep the hard refusal — it is correct. Add credential routes that do not pass through
argv:

1. --auth-file PATH — read USER:PASS from the first non-empty line; warn when
   the file is group- or other-readable. The secret then sits behind filesystem
   permissions instead of being published.
2. --auth-prompt — read interactively at startup. Never touches argv, the
   environment, or the disk. Best for one-off manual runs, not for unattended ones.
3. Optionally accept an environment variable. Weaker than (1): /proc/<pid>/environ
   is still readable by root, and the value is inherited by child processes.

--auth should stay for single-user machines, with a note in --help about its
exposure so the trade-off is visible at the point of use.

Status

I have a working implementation of (1) locally — a _read_auth_file() helper, mutual
exclusion against --auth, and the permission warning. Happy to open a PR if the
approach looks right.