Per-session mount role grants (read/write/exec)

[zechengz]

What

Sessions can be restricted to per-mount roles. The mount's configured mode is the ceiling; a session grant can only narrow it on the READ < WRITE < EXEC lattice.

• SDK: ws.create_session("agent", mounts={"/data": "read", "/scratch": "write"}); a plain list keeps the previous allowlist behavior (mount's own mode). TS: ws.createSession(id, { mounts }).
• CLI: mirage session create WS -m /data:read -m /scratch:write (bare -m /data inherits).
• Server: POST /sessions {"mounts": {...}}, dict or list; invalid role returns 422.
• Enforcement rides the existing read-only checks via effective_mount_mode, so a session-denied write produces the same stderr as a read-only mount. The python builtin exec gate is per-session now. Grants survive fork, background jobs, and snapshots.

Behavior changes

• A user-defined / mount is now governed by grants instead of bypassing the allowlist (the documented escape hatch). The implicit scratch root stays auto-granted so pathless commands keep working in restricted sessions.
• Python capability errors now carry the GNU-style command prefix (cat: session 'x' not allowed ...), matching TS.
• mirage/runtime is renamed to mirage/context (TS core/src/context).

Testing

• New 1:1 unit tests for the context module plus workspace grant suites in both languages; existing capability/jobs/fork regression tests updated.
• New integ/grants.py / integ/grants.ts with byte-identical output against truth_grants.txt, wired into both integ legs.
• Python full suite green (known jina flake excluded); TS core 3561, server 148, cli 51 green; pre-commit green.