Close the browser-verification gap: the front end has now been run

Deletes known issue 3. users.js, wp-sidenav.js and the extracted console.css had
never been executed, because there is no node/deno on the machine they were written
on. Edge is, so the pass was driven through the DevTools Protocol with a hand-rolled
stdlib WebSocket client, signing in by minting a session with the app's own
auth.create_token() rather than scripting the login form.

70 checks, twice, all passing — covering the five steps that entry listed:

  1. users.html as an admin: 9 columns, one-line rows, no sideways scroll, all four
     grantable roles, the project-access dialog opening and closing on Escape, and
     your own permissions cell locked to a tag while your job function stays editable.
  2. As a Project Super User: banner naming the project, only in-scope accounts
     listed, out-of-scope rows read-only with the reason on hover, and exactly the
     two roles they may grant.
  3. As an ordinary project user: 6 columns, no create form, zero controls, emails
     still reachable as mailto links.
  4. field.html: drawer opens, closes on Escape and on the scrim, aria-expanded and
     aria-current correct, focus moves inside, 44px tap targets, Admin Console hidden
     from non-admins, and ?project= carried onto project-scoped links only.
  5. admin.html: console.css loaded, --ctl resolving, cards and headings and sticky
     dense tables intact after the extraction, user administration gone and replaced
     by a link, and the admins-only gate still holding for a non-admin.

Every page boots with no JavaScript errors, which was the actual unknown.

Two things the pass surfaced, neither a defect: a 404 on /api/sops/latest is the
API's designed answer for a project with no SOP ("No SOP found") and the browser
logs every 4xx, so the fixture now seeds one; and role pills only appear where a row
is rendered read-only, since an editable row shows a dropdown instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

KNOWN-ISSUES.md

@@ -12,7 +12,6 @@ Close an entry by deleting it in the same commit that fixes it.
 |---|-------|----------|--------|--------|
 | 1 | XSS via SOP discipline names in the WP creator | Medium (internal), High if externally reachable | 2026-08-05 | Open |
 | 2 | Archived projects: the two big apps don't grey out their own controls | Low | 2026-08-05 | Open |
-| 3 | User Directory and nav drawer have not been run in a browser | Low (verification gap, not a known defect) | 2026-08-05 | Open |
 
 ---
 
@@ -162,65 +161,3 @@ save/issue controls, or add a boot check in each app that disables them and show
 read-only notice inline. Decide separately how the embedded creator
 (`wp-creation-index.html`) surfaces it, since it runs in an iframe where the shared
 app bar — and therefore the banner — is deliberately skipped.
-
----
-
-## 3. User Directory and nav drawer have not been run in a browser
-
-**Files:** `html/users.html`, `html/users.js`, `html/wp-sidenav.js`,
-`html/wp-sidenav.css`, `html/console.css`
-**Raised:** 2026-08-05, with the Project Super User work.
-
-### What is wrong
-
-This is a **gap in what has been verified, not a known defect.** The machine the code
-was written on has no JavaScript engine available (no node, deno, or npx), so these
-files have never been executed. What *has* been checked:
-
-- The server side they talk to: 93 scope/permission tests and 29 live HTTP tests
-  through the real dependency stack, all passing.
-- Static analysis of the browser code: delimiter balance across all scripts (with a
-  tokenizer that handles nested template interpolation), every inline handler
-  resolving to a defined function, every `getElementById` target existing in its page,
-  and no leftover references to the functions that moved out of `admin.js`.
-
-What that cannot cover is anything only a browser decides: CSS layout, the drawer's
-open/close transitions and focus trap, event wiring, and how the three role
-renderings actually look with real data.
-
-### What it costs
-
-Unknown by definition, bounded by blast radius. A syntax or boot error in `users.js`
-means a blank User Directory — obvious the moment anyone opens it, and it takes
-nothing else down: `users.html` is a new page, and the drawer is additive to pages
-that already worked without it. The server-side role and its scope rules are
-independently tested and unaffected either way.
-
-The one thing to watch is `console.css`, which was extracted from `admin.html`'s
-inline styles and is now shared. A rule lost in that move would show up as the Admin
-Console losing its dense-table styling — the same symptom the deploy runbook already
-tells you to look for ("one line per user", not three).
-
-### Why it is still open
-
-It closes with one manual page load, which needs a browser signed in to a real
-deployment — not something to fake from a test harness.
-
-### What closing it takes
-
-Minutes. Hard-reload first (Ctrl+Shift+R) — the service worker caches the app shell
-and `sw.js` bumped to `wp-suite-shell-v6`, so a normal reload can serve the old file
-list and make a good deploy look broken.
-
-1. Open **users.html** as an admin: the table renders, rows are one line tall, and
-   the Permissions and Project role dropdowns are populated.
-2. Open it as a **Project Super User**: the blue scope banner names their project(s),
-   the create form demands at least one project, and any account also on a job they
-   don't administer shows as `read-only` with a reason on hover.
-3. Open it as a **project user**: six columns, no controls, no create form.
-4. Open **field.html** on a phone or a narrow window: the ☰ opens the drawer, Escape
-   and the scrim close it, and Admin Console appears only for admins.
-5. Open **admin.html** and confirm the tables still look dense and correct — that is
-   the `console.css` extraction check.
-
-Delete this entry once those five are done.