#2728 Docs: serve authorizes requests by id against the resource's name

After swamp-club#2674, swamp serve resolves the model, workflow or model data a request names — by name or by UUID — and authorizes the resolved resource's canonical name and fields, then acts on it by id. The manual page content/manual/reference/swamp-serve/authorization.md explains that grant selectors match resource names but not how requests by id are matched. Add:

1. A request may name a model or workflow by name or UUID; either way the grant is checked against the resource's name and fields, so deny model:prod-* also blocks a request by prod-db's UUID, and tag conditions apply the same way.
2. Lookup order is name first, then exact id. A resource named with another resource's UUID wins over the resource with that id. This also applies to the CLI's workflow get, delete, edit and validate for UUID arguments, which previously looked a UUID up by id only.
3. Run cancel and attach are authorized on the run's own model or workflow, found by the id recorded when the run started.
4. A workflow file that fails to parse is authorized on the name it declares and carries no tags, so tag-conditioned rules do not apply to it.
5. Forms that still authorize differently today: direct type execution (swamp-club#2672), '*' resources (swamp-club#2675), vaults (swamp-club#2676).
6. Output and run id prefixes (model output get/data/logs, model method history get/logs, workflow history get/logs), after swamp-club#2673: a 3+ hex-char prefix is resolved to the output or run it matches, and the grant is checked against the model or workflow that owns it, never the prefix. A model or workflow sharing that id with a copy is checked on every owner, and one deny refuses. A read by name is also checked against the owner of the latest output or run it returns. Outputs of a deleted model are checked on the model id; runs of a deleted workflow on the workflow name recorded on the run. A prefix that matches several outputs or runs, or none, is checked as sent.
7. Data content through outputs, after swamp-club#2739: model output data and model output logs return data artifact content, so they need a data read on the owning model (as data get does) as well as the model read. A principal granted only model reads can no longer read artifact content this way.

Design reference: design/enablers/access-control.md, section 'Requests by id match the resource's name'.