S6 Origin — Authoritative Authentication (normal login)

This is the authoritative origin. It is the normal "before" login system for scenario S6. It owns its own credential verifier and password history. The S6 capability Worker (s6.thecompany-lab.com) sits in front of it and calls the scoped internal endpoints below to perform an authoritative, no-session credential check before opening password-remediation state — it never sees this origin's verifier or history material.

Direct hostname: s6-origin.thecompany-lab.com
Capability hostname: s6.thecompany-lab.com

Endpoints

Method	Path	Scope	Purpose
GET	`/`	public	This page
POST	`/login`	public	Normal browser + API login. Success establishes a session (browser: session cookie + 302; API: success JSON). Failure returns a single generic error (no user enumeration).
POST	`/internal/auth/verify-password`	service-secret	V1 authoritative no-session credential check. Returns only `{ valid: true\|false }`. Never sets a cookie, issues a token, or redirects.
POST	`/internal/auth/reset-password`	service-secret	Idempotent admin reset (Option A). Rejects recent-password reuse via the origin's own password history. Returns `{ ok }`.

Scoped endpoint access

The two /internal/* endpoints require the shared service secret in the x-rs-service-secret request header, supplied only by bindings / local environment (see .dev.vars.example). Requests without it are rejected with 403 before any account work.

Password handling: submitted passwords exist only in request memory for the handler. They are never logged and never copied anywhere beyond this origin's own one-way verifier and history. The "no password persistence" PoC rule constrains the capability's edge pending store, not this authoritative origin.