excalidraw: grant emo-browser SA port-forward for drawing uploads

Viktor asked to fix emo's permission so his Claude can upload to the
Excalidraw service. emo's recent sessions show the documented upload
recipe (kubectl port-forward svc/draw + X-Authentik-Username header,
from his ~/.claude/CLAUDE.md) failing with:

  pods/portforward forbidden for system:serviceaccount:chrome-service:emo-browser
  in namespace excalidraw

because his default kubeconfig is the read-only emo-browser SA (its
port-forward grant covers only chrome-service) and his old admin
kubeconfig at /home/emo/code/config expired and was removed.

Add a namespace-scoped Role (pods/portforward create) + RoleBinding for
that SA in the excalidraw namespace, mirroring the 2026-06-28
chrome-service grant. Trade-off (any-user drawings via the trusted
username header) documented in the file and accepted.

Also record the grant in docs/architecture/chrome-service.md.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/architecture/chrome-service.md

@@ -329,6 +329,12 @@ Two independent grants make up "browser access" for a user:
 the provisioner. To revoke: remove from `CHROME_ALLOWED` and delete the SA (rotate
 a token by deleting its `<user>-browser-token` Secret).
 
+Because the SA is the user's DEFAULT kubectl credential, other per-namespace
+port-forward grants hang off the same identity: `stacks/excalidraw/rbac.tf`
+grants `emo-browser` `pods/portforward` in `excalidraw` (2026-07-02) so emo's
+agent can upload drawings via the port-forward + `X-Authentik-Username` recipe
+in his `~/.claude/CLAUDE.md`. Revoking the SA revokes those too.
+
 ## Limits + risks
 
 - **Anti-bot vs stealth arms race** — when an upstream beats us (DRM