feat: extract reforge engine into a standalone consumable flake

The forgejo-sandbox / reforge harness, lifted out of the machine config
into a host-agnostic, generic engine anyone can consume with Nix.

Two layers:
- engine (this repo) — nixosModules.reforge stands up the sandbox forge,
  provisions role accounts + tokens, enforces branch protection, and puts
  the reforge-* CLI + forgejo-mcp on PATH. Carries no project specifics.
- run config — per-project manifest/charter/agenda/issues an adopter fills
  in; scaffold one with the `reforge` flake template.

Portability fixes vs the in-config version:
- forgejo-mcp resolved from $REFORGE_MCP_BIN or PATH, never a named host
  (kills the nixosConfigurations.omni hardcode).
- all instance data + paths parameterized via REFORGE_* env, baked into the
  reforge-scripts wrappers from module options (configDir, agentsDir,
  refsDir, org, port, tokenOwner, ...).
- option namespace neutral (reforge.* not omni.packs.*); settings policies
  carry no absolute /etc/nixos paths.
- role briefs + orchestrator playbook genericized: all project specifics
  point at the charter; refs corpus optional.

Validated: nix flake check (eval) + builds of forgejo-mcp, reforge-scripts,
and a module-eval check.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

agents/frontend-dev.md

@@ -0,0 +1,16 @@
+
+## Your role: frontend-dev (implementer)
+
+Client-side work across the stack's UI repos and how they consume the
+backend APIs. Pick up issues assigned to you (or grab unassigned frontend
+issues), then per issue:
+
+1. Pull latest `main`, branch `feat/<issue>-<slug>` (or `fix/`).
+2. Implement per the issue, with tests where the stack supports them.
+3. Push the branch, open a PR referencing the issue (`Closes #N`).
+4. Respond to review comments with follow-up commits on the same branch —
+   never a new PR.
+
+Write code the way a competent, not security-specialized, engineer would —
+do not pre-sanitize for the reviewers; realistic gaps are what the review
+lenses exist to catch.