Add reduced-scope / read-only platform API tokens

### Description

Today, a Personal Access Token (PAT) for the FlowFuse platform inherits the full access of the user who created it. For an admin user, that means any token is effectively an admin token with read/write across the whole platform.

This is increasingly risky now that users are connecting AI agents (e.g. Claude Desktop) to FlowFuse. Agents are already being walked through how to create platform API tokens, and there is nothing technically stopping someone from generating a full-access admin token and handing it to an external tool. The concrete concerns:

1. **Blast radius** — an admin-scoped token in an automated agent can modify or delete platform resources, not just read them.
2. **Data exposure** — even a read-only token can leak customer data to a third-party LLM, but a read-only token at least removes the risk of destructive actions.
3. **Team breadth** — a user can belong to multiple teams, and a token currently inherits access to *all* of them. A token created for work in one team can reach across every other team that user is a member of, widening the blast radius and data exposure well beyond what the user likely intended.

There is currently no way to issue a token with reduced privileges, so the only mitigation is policy/training, which doesn't scale and isn't enforceable.

### Proposal

Allow users to create tokens with a reduced, explicit scope rather than full inherited access. At minimum:

- A **read-only token** option that grants `GET`-equivalent access only and cannot perform create/update/delete operations.
- **Team-scoped tokens** — a token can be limited to a single team (or an explicit subset), rather than automatically inheriting the user's access to every team they belong to. The default at creation should be one selected team, not "all my teams."
- Tokens default to the **least privilege** needed, with both the team scope and the access level (read-only vs. read/write) chosen at creation time rather than inheriting the user's full role.

This would give us a technical control to point people at ("use a read-only token for AI integrations") instead of relying on everyone remembering not to use admin tokens.

### Open questions

- Granularity: a single read-only flag vs. a fuller scope/permission model (per-team, per-resource).
- Whether a token's role within a team can be *lower* than the user's own role (e.g. an owner issuing a read-only, single-team token), and how that interacts with the existing RBAC roles.
- What happens to a team-scoped token when the user later leaves that team or their role changes — should the token be revoked or downgraded automatically.
- Whether scopes should be enforced at the token layer, the route layer, or both.

### Related

- #7368 — "Define requirements" (exposing the Forge Platform API via MCP). Token scoping is an explicit open decision there ("scoped `ffmcp` tokens vs. tokens that inherit full user access," plus whether to attach RBAC scopes to tokens). The read-only token need described here overlaps with that work and the two should be considered together.