Harden sign-in, and show what a Bot is doing

[davidmckayv]

Two pieces of work. Five findings from a review of #67, and the surface that answers "what is it
doing" when the Bot is not in a browser.

The five

Running with no sign-in was gated on NODE_ENV === "production", which is exactly backwards.
NODE_ENV is unset unless somebody sets it, so the one deployment the check existed to catch, a
container on a VM with a hand-written env file and no identity provider, was the one it let through:
every visitor on the internet served as an administrator, silently, because nothing looked wrong from
the outside. It now takes an explicit OPENBOT_SINGLE_USER=true and refuses to start without one.
.env.example ships that line switched on, so a clone still runs with no configuration at all, and
the line is greppable in a way a default never was. The most dangerous boolean in the codebase had no
test; it has a file now.

accounts.issuer no longer takes NOT NULL in the same release that adds the column. A rolling
deploy runs the migrations and then serves from old and new replicas at once, and an old replica
inserts an account without the column: under NOT NULL the release breaks the first sign-in of
everybody who lands on a replica that has not been replaced yet. 0004 is gone and the rule is
written down in docs/development.md, where the next person will hit it.

A registered identity provider belonged to whoever registered it. Better Auth answers
GET /sso/providers with providers.filter(p => p.userId === session.user.id) and refuses a delete
from anybody else, so a second administrator opened the screen, found it empty, and registered a
provider that already existed. The row also cascaded from that person's user row, so deleting the
administrator who set sign-in up deleted the company's sign-in with them. Reads and removals now go
through our own admin-gated routes against the whole table, and the foreign key is set null.

A customer's client secret was in the clear. The SSO plugin writes oidc_config and saml_config
as plaintext JSON with the OAuth client secret inside: the one secret here not going through
KEY_ENCRYPTION_KEY. The plugin offers no hook, so the seam is the storage adapter. Rows written
before this still read and are re-encrypted on the next write. OAuth access and refresh tokens use
Better Auth's own encryptOAuthTokens, deliberately theirs rather than hand-rolled inside somebody
else's storage layer.

Sign-in left no trace at all. Nothing recorded that somebody who could edit
INITIAL_ADMIN_EMAILS had granted themselves the role, and revoking a person deletes the sessions
that were the only evidence they had ever been here. There are now rows for signing in, for being
turned away, and for the configured floor granting the role, and a trail that is down never blocks a
sign-in.

Watching a Bot work

The screen answered half the question. A Bot that spends two minutes in a terminal shows a blank
browser, and the transcript gives it one grey line per command with the output nowhere: the model
saw it, decided which part mattered, and the person watching had to take its word. That is a poor
deal on a machine holding somebody's logins.

The transcript line now opens to show what the command printed, its exit code, and whether it was cut
short or stopped. Beside the screen there is an Activity tab carrying every command, file read, write
and listing as they happen, with a count on the tab so a Bot working away from the browser is visible
without switching to it. A saved file shows its path and size, never its contents, matching the write
route.

This is a window, held in the browser for the open conversation. The record is the audit trail.

Where it runs

• New state that outlives a request? No new tables. sso_providers.user_id becomes
  set null, and accounts.issuer stays nullable.
• What happens on the second replica? Nothing here is per-process. Activity is per-browser
  and deliberately not shared: it is a view of one person's open tab, not a record.
• Anything serialised? The SSO config, through the adapter wrapper, in the same envelope
  format the credential vault uses.
• New listener, port, or schedule? None.

Proof

Driven in a browser on a real deployment with Google configured:

• Registered an OIDC provider and confirmed SUPER-SECRET-ACME-VALUE-12345 appears in zero rows of
  sso_providers, and that the column holds a version-1 envelope.
• Deleted the user who registered it. The provider survived with user_id null, still listed, and
  still removable from the screen, which Better Auth's own route would have refused.
• Signed out and back in through Google. session.signed_in landed with the address on it.
• Removed the provider through the UI; identity_provider.removed landed naming who did it.
• Ran a Bot through commands, a file read, a file write, a listing and a deliberate failure, and
  checked both surfaces: Exit code 2 and the stderr in the pane and behind the chevron.

bun test: 606 pass in server, 114 in app, with the two pre-existing
server-side-tools.integration failures that are identical on main. bun run typecheck clean.
bun run format:check clean. drizzle-kit check reports everything's fine and the journal agrees
with the directory.

Docs updated: CHANGELOG.md carries the history, README.md stays about getting started, and
docs/configuration.md, docs/architecture.md, docs/deployment.md and docs/development.md each
take the part that is theirs. One operational note found by driving it: registering an OIDC provider
needs every host in its discovery document in TRUSTED_ORIGINS, not only the issuer.