feat(mcp): profile-level read-only enforcement (KLA-409)

[jklaassenjc]

Summary

Closes KLA-409 — Slice C (the only remaining piece; allow/block lists and --read-only already shipped).

Adds a profile-level role field (auth_profile_role: read_only) so a profile bound to a read-only JumpCloud OAuth client can't accidentally be started in mutation-capable mode:

• config — ProfileRole(profile), IsReadOnlyProfile(), SetProfileRole() with validation. Only ProfileRoleReadOnly ("read_only") is accepted; unknown values are rejected at set-time so typos don't silently fail to enforce anything.
• jc mcp serve — new applyProfileRole() helper coerces readOnly = true when the active profile carries the role, emits a one-line stderr warning if the operator hadn't already passed --read-only, and rejects the start with a clear error if --read-only=false was passed explicitly.
• jc auth status — surfaces a Profile Role line (and profile_role JSON field) when set; omits it otherwise to keep output clean for the 99% case.

Why

Today an operator can set up the right pattern (read-only OAuth client → dedicated jc profile → MCP-server use only) but still misconfigure the start command and end up advertising mutation tools that will only fail at the JumpCloud API layer with 403s. That's noisy, confusing in audit logs, and defeats the point of having a read-only credential. This adds a startup-time gate that closes the loop.

Behavior matrix

Profile role	--read-only flag	Result
not set	unset / true / false	unchanged (existing behavior)
read_only	unset	coerced to true; warning on stderr
read_only	true (explicit)	runs read-only; no warning (operator and profile agree)
read_only	false (explicit)	startup error with profile name + reason

Test plan

• go build ./... clean
• go test ./... — full suite passing
• config: 4 new tests cover default-empty, read-only profile detection, SetProfileRole round-trip, invalid-role rejection
• mcp: 4 new tests on applyProfileRole cover all branches of the matrix above
• auth: 2 new tests cover the status output presence/absence of the Profile Role line

Follow-up

docs/AUTH.md (which lands in #21 / KLA-410) will get a small section on the profile role once that PR merges. This PR is code-only to avoid a stacked-PR conflict.

🤖 Generated with Claude Code

---

Note

Medium Risk
Medium risk because it changes jc mcp serve startup behavior (new coercion/warnings and a hard error for incompatible flags) and introduces new config fields that affect runtime enforcement.

Overview
Adds a new profile-level role (profiles.<name>.auth_profile_role) with validation helpers (ProfileRole, IsReadOnlyProfile, SetProfileRole) to support a read_only profile mode.

Updates jc mcp serve to enforce read-only profiles via applyProfileRole(): it forces --read-only on when the active profile is read-only (emitting a stderr warning if not explicitly set) and fails fast if the operator explicitly passes --read-only=false.

Extends jc auth status to include the profile role in both human output and JSON (profile_role), omitting it when unset; adds targeted unit tests for the new status output, role helpers, and enforcement matrix.

^{Reviewed by Cursor Bugbot for commit 9a3dc17. Bugbot is set up for automated code reviews on this repo. Configure here.}