Add sentryctl dashboards permissions list|grant|revoke

PUT/DELETE /dashboards/{id}/permissions/{userId} (per-resource dashboard
grants, built earlier this phase) had no caller but Go tests and curl --
named as a real, disclosed gap in docs/phase-4-runbook.md. Adds a CLI
surface: sentryctl dashboards permissions list/grant/revoke, following
the existing dashboards subcommand pattern.

grant/revoke needed a new httpclient.go helper (httpMutateNoBody) since
both endpoints respond 204 No Content -- the existing helpers all expect
a JSON body to pretty-print. grant validates the role client-side
(viewer/editor only, mirroring api/dashboards.validGrantRole) before
making a request, since Admin/Owner already have tenant-wide dashboard
access and a resource-level grant can never raise someone past Editor.

Verified with real httptest.Server round trips (method, path, request
body, and error-body parsing on a 501 from a deployment with no
enterprise permission service wired in) -- the same pattern every other
sentryctl subcommand's tests already use, no fake/mock client needed
since sentryctl itself is just an HTTP client with no store of its own.

cli/README.md

@@ -31,11 +31,24 @@ sentryctl dashboards list
 sentryctl dashboards get <id>
 sentryctl dashboards apply dashboard.json    # imports a dashboard exported via the web UI's "Export JSON" button
 
+sentryctl dashboards permissions list <dashboard-id>
+sentryctl dashboards permissions grant <dashboard-id> <user-id> viewer|editor
+sentryctl dashboards permissions revoke <dashboard-id> <user-id>
+
 sentryctl alerts list
 sentryctl alerts get <id>
 sentryctl alerts apply rule.json             # creates a rule from a JSON file shaped like POST /rules's body
 ```
 
+`dashboards permissions` is Phase 4's per-resource dashboard grant
+(`api/dashboards.PermissionStore`) — additive-only, raises someone to
+`viewer` or `editor` on one specific dashboard (Admin/Owner already have
+tenant-wide access, so the server rejects any other role). On plain
+`api` (no `enterprise-api`, no permission service wired in) every
+`permissions` call fails with a 501 whose message says so explicitly —
+that's the deployment telling you this feature isn't available, not a
+CLI bug.
+
 `dashboards` talks to `/api` (`--api`, same override as `query`/`ping`).
 `alerts` talks to `/alerting`, a separate service with its own base URL
 (`--alerting-api`, or `$SENTRYCTL_ALERTING_API_URL`, default