Spike: validate runtime login for LoginWindow on OpenBSD (OpenPAM vs native bsd_auth)

## Type
Spike / investigation (time-boxed). No production code required to close — the deliverable is findings + a recommendation (and a follow-up implementation ticket if needed).

## Background
As part of the OpenBSD port (gershwin-developer#33), `LoginWindow` is built entirely on **PAM** (`LoginWindowPAM.m`, `#include `, links `-lpam`). OpenBSD has **no PAM in base** — it uses its own **BSD Authentication** framework natively.

To get LoginWindow to **compile and link** on OpenBSD we installed the `security/openpam` port (the FreeBSD/macOS OpenPAM implementation, which ships `pam_appl.h` + `libpam` under `/usr/local`). LoginWindow's GNUmakefile already links `-L/usr/local/lib -lpam`, so it builds with no code change.

**But building is not the same as working.** OpenPAM is only the *framework* — actually authenticating a user requires PAM modules (e.g. `pam_unix`) and an `/etc/pam.d` configuration, and on OpenBSD passwords live in `master.passwd` (bcrypt) behind the BSD-auth machinery. So it is currently **unknown whether a user can actually log in** via OpenPAM on OpenBSD.

> Note: this ticket is predicated on the openpam approach getting LoginWindow to build green in gershwin-developer#33. If it does not build, that's a separate blocker.

## What OpenBSD uses instead (to document)
OpenBSD authenticates via **BSD Authentication** (`bsd_auth(3)`), not PAM:
- `auth_userokay(name, style, type, password)` — the simple one-call password check.
- Login classes / capabilities via `login.conf(5)` + `login_cap(3)` (`setusercontext()` for setting up the session: uid/gid, resource limits, environment, login class).
- Auth styles are implemented as separate `login_*` helper programs (e.g. `/usr/libexec/auth/login_passwd`), run as distinct processes — a deliberate privilege-separation design.
- No `/etc/pam.d`, no `pam_*` modules, no `shadow.h`.

References: `man.openbsd.org/auth_userokay.3`, `man.openbsd.org/login.conf.5`, `man.openbsd.org/setusercontext.3`, https://en.wikipedia.org/wiki/BSD_Authentication

## Spike questions to answer
1. With `openpam` installed, does LoginWindow's `LoginWindowPAM` actually authenticate a real OpenBSD user at runtime (correct password accepted, wrong password rejected)?
2. If not out of the box, what is the minimum to make it work? (an `/etc/pam.d/` config? a working `pam_unix`/`pam_login`-equivalent module on OpenBSD that validates against `master.passwd`? does such a module even exist/port cleanly?)
3. Does session setup work — environment, credentials, `openSession`/`openSessionAsUser`, `getEnvironmentList` — or only the auth step?
4. Is relying on OpenPAM on OpenBSD robust and idiomatic, or fragile (non-standard, extra config, security caveats)?

## Likely outcomes
- **A — OpenPAM works** with some pam.d config: document the required config, ship it, done.
- **B — OpenPAM is insufficient/fragile**: implement a native **`bsd_auth` backend** — a `LoginWindow` auth class mirroring the `LoginWindowPAM` interface (`authenticateUser:password:`, `openSession*`, `getEnvironmentList`, `closeSession`) using `auth_userokay()` + `login_cap`/`setusercontext()`, gated on OpenBSD, with PAM kept for Linux/FreeBSD. Open a follow-up implementation ticket.

## Acceptance criteria
- [ ] Documented whether a user can log in via LoginWindow on OpenBSD with the current OpenPAM-based build (with steps/evidence).
- [ ] Documented OpenBSD's native auth model (`bsd_auth`) and how LoginWindow would map onto it.
- [ ] Clear recommendation: keep OpenPAM (+ required config) **or** implement a `bsd_auth` backend, with a follow-up ticket if the latter.

## References
- gershwin-developer#33 (OpenBSD port)
- `LoginWindow/LoginWindowPAM.{h,m}`, `LoginWindow/GNUmakefile`
- OpenPAM port: https://openports.se/security/openpam

Start with LoginWindow/LoginWindowPAM.{h,m} and LoginWindow/GNUmakefile, then run the built LoginWindow on OpenBSD with OpenPAM using correct and incorrect credentials. Check whether authentication and the session methods work, recording required configuration and evidence. Document the native bsd_auth model and recommend OpenPAM or a follow-up backend ticket.

Written by the indexing model from the issue text.