Fix the WP navigator and the squeezed embedded layout; add per-project permissions

Layout — the reported "skinny scrolling windows"
- .content-area capped the whole suite at 1000px, so on a 1920 screen the embedded
  Work Package Creator ran in a ~930px column with its own scrollbar inside the
  page's. The wizard now caps at 1700px and the Creator/Dashboard tab goes
  full-bleed: the iframe fills the window below the app chrome and owns the only
  scrollbar. Needed `flex: none` on the content area — as a `flex: 1` item its
  flex-basis overrode `height`, leaving the used height indefinite so the child's
  `height: 100%` collapsed the iframe to its 150px default.
- The SOP wizard's fields were one per row; they now flow into ~340px columns.

Navigator — now an auto-hiding drawer
- It was a fixed 262px column that stole width from the form AND was hidden below
  1100px, so embedded (the normal path) it never appeared at all — that's the
  "broken side menu". It's now an overlay drawer behind a slim always-visible edge
  handle: hover or tap to open, move away / Escape / pick a package to close, or pin
  it to keep it open (pinned shifts the form and the page chrome across, and is
  remembered). A gutter keeps the handle off the section-nav chips.

Bugs found while checking the site over
- collectStepData() still read the SOP team fields as text inputs, but wave 1 made
  them account pickers — so it wrote a user ID into state.team.pm where the display
  NAME belongs, and the SOP would print `user_ab12…` as the PM. Now synced properly
  from the pickers.
- loadSampleData() set .value on those selects with fictional names; setting an
  unmatched value on a <select> silently does nothing, so the sample lost its team.
  It now stores them as names without an account, which the picker shows as
  "(no account)".
- My earlier CSS block replacement had deleted the SOP-chip, people-picker and
  critical-tag styles. Restored.

Same picker everywhere the SOP names someone
- Sign-off roles (step 3, required and optional) are account pickers now, storing
  userId alongside the name, so a signature belongs to an account that can be
  notified. Titles stay free text.

Per-project permissions (asked for: "change project permissions for individual users")
- project_members.role overrides the account's role on that project, so a PM on one
  job can be a Project User on another. Empty = inherit; app admin is admin
  everywhere. effective_role() feeds require_project_admin, so WP delete, completed-
  SOP edits and project delete are all judged per project.
- Project access is now its own column in the admin console (it was buried among the
  action buttons, which is why it couldn't be found), showing the project count per
  account; the dialog sets access plus the role on each project.
- The members endpoint reports each person's effective role on that project.

Verified: 157 API checks across five suites on clean databases (44 permissions +
22 password reset + 34 search/localization + 39 gates/notifications + 18 new
per-project permission checks), 16 drawer-behaviour + 4 pinned-mode UI checks driven
in headless Chrome, and probes confirming the team/sign-off pickers populate and no
longer corrupt state.team on step navigation. Screenshots reviewed at 1920x1080.

Service-worker cache bumped to v3 so browsers pick up the new shell.

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

DEPLOYMENT.md

@@ -446,3 +446,26 @@ For a quick local look, the API falls back to a SQLite file when `DATABASE_URL`
 is unset (`sqlite:///./wpsuite.db`) — see [`server/README.md`](server/README.md)
 § *Local dev*. The front end alone can also be served statically from `html/`
 (it falls back to browser storage when the API isn't reachable).
+
+## Per-project permissions
+
+`users.role` is the account's **default** permissions role. A membership row can
+override it **per project** (`project_members.role`), so someone can be Project
+Admin on one job and a plain Project User on another. Empty means "inherit the
+account's role", which is how every pre-existing membership behaves.
+
+Resolved by `effective_role()` in `server/app.py`; `require_project_admin()` uses it,
+so deleting a work package, changing a completed SOP and deleting a project are all
+judged **on that project**. An app `admin` is admin everywhere and bypasses
+membership entirely.
+
+Set it in **Admin console → User administration → Project access** (its own column,
+showing how many projects each account can reach). The dialog ticks project access
+and picks the role on each; `/api/auth/users/{id}/projects` takes
+`{project_ids: [...], roles: {project_id: role}}` and only accepts the two
+project-scoped roles. Changes are audit-logged as `project_access_changed`.
+
+**Who appears in the SOP's people pickers** is `GET /api/projects/{id}/members` —
+the project's members plus app admins, each with their effective role on that
+project. A project with nobody assigned shows only the admins, which is why
+assigning people is the first step on a new job.