docs(audiobookshelf): the phone app's connection facts and where its token lives

The page told an agent how to sign in from a browser and nothing about the phone.
Measured 2026-11-03 on the deployed service:

- Server Address `http://192.168.0.235:8000`, user `frank`, plain HTTP, no base-path
  prefix; `/healthcheck` and `/ping` answer 200 from a second host on the LAN and
  `iptables -S INPUT` has no rule for 8000, so no phone-side setup is needed.
  `download: true` on the root account is what enables offline listening.
- `POST /login` puts the bearer at `user.token`, not top level. Reading
  `response.token` yields "", the client sends `Authorization: Bearer ` with nothing
  after it, and every `/api/*` answers 401 as though the password were wrong — which
  it was not. That is the failure I hit inside five minutes of scripting this.
- The LAN-only law gains its consequence for clients: the Anubis + Authentik chain
  serves browsers, so guarding a vhost does not make the phone app work remotely.
  Remote listening wants a VPN into the LAN; the LAN address is then still correct.

bats: 822 seams green.

serverAppConfigs-docs/Dankserver/Audiobookshelf.md

@@ -65,6 +65,22 @@ never `/healthcheck`. It also reads files that are genuinely broken and logs
 `[AudioFileScanner] Invalid data found when processing input` per file — that is
 the file, not the bind: the same line count grows while the total climbs.
 
+## Phone app
+
+The official **Audiobookshelf** app connects with Server Address
+`http://192.168.0.235:8000`, username `frank`, and the same password as the web UI —
+no base-path prefix, plain HTTP. Verified from a second host 2026-11-03: `/healthcheck`
+and `/ping` answer 200 across the LAN and `iptables -S INPUT` carries no rule for 8000,
+so a phone on `192.168.0.0/24` connects with no further setup; `download: true` on the
+root account is what makes offline listening work. Away from the LAN it cannot connect —
+see the LAN-only law, and note that the guard chain is not the remedy there.
+
+**The login token is at `user.token`, not top level.** `POST /login` answers
+`{ user, serverSettings, ereaderDevices, Source, userDefaultLibraryId }` and the bearer sits
+inside the user object. A client that reads `response.token` gets the empty string, sends
+`Authorization: Bearer ` with nothing after it, and every `/api/*` call then answers `401`
+as though the password were wrong.
+
 ## Laws
 
 - **Speak the image's env names, not the README's.** The server reads `PORT`,
@@ -108,7 +124,10 @@ the file, not the bind: the same line count grows while the total climbs.
 - **LAN-only until Frank says otherwise.** `0.0.0.0:8000` with no reverse proxy
   in front. Any public vhost requires the Anubis + Authentik chain first, and the
   outpost proxy provider has to exist before the vhost flips (external exposure
-  policy in `AGENTS.md`).
+  policy in `AGENTS.md`). That chain serves browsers: the phone app is a non-browser
+  client and cannot solve a challenge, so guarding a vhost does not make remote
+  listening work — remote listening wants a VPN into the LAN, after which the LAN
+  address in *Phone app* is correct unchanged.
 - **There is no `/setup` route; the creation door is `POST /init`.** `/status`
   (no `/api` prefix) reports `isInit` = "a root user exists", `POST /init` with
   `{"newRoot":{"username","password"}}` creates it, `POST /login` returns the