Trusted connections: use a transient super-user identity (no stored user required)

"Trusted" connections (e.g. Unix-domain-socket / local) currently authenticate by assigning the cluster's super user as the current user (see `security/auth.ts:235`). This couples trusted-connection auth to the existence of a super user — and prevents a zero-user Harper installation.

## Ask

Replace that mechanism with a transient super-user identity: no `username`, just the `super_user` privilege. Downstream code that checks privileges sees the same `super_user = true` it sees today; code that *names* the user gets `null` / `undefined`.

## Why this matters

- Cleaner separation: trust at the connection layer (UDS, etc.) shouldn't depend on a stored user account.
- Enables a zero-user Harper installation (no need to seed an admin account just to bootstrap).
- Reduces blast radius if the stored super-user account is later compromised — trusted connections don't impersonate that specific account.

## Acceptance criteria

- Trusted connections operate with full privilege without referencing a stored user account.
- Audit logging still records the action (e.g. `actor: ''` or similar marker) — verify what audit downstream expects.
- A Harper installation without any stored user can still be administered via a trusted connection.
- Existing user accounts and the operations API continue to work unchanged.

## Notes

- Reference: [security/auth.ts:235](https://github.com/HarperFast/harper/blob/main/security/auth.ts) (line numbers may have shifted).
- Verify the change doesn't break the operations API expectation that `currentUser.username` is always set somewhere downstream.

---

Tracked in Jira: [CORE-2963](https://harperdb.atlassian.net/browse/CORE-2963)

🤖 Filed by Claude on behalf of Kris.