Link views from the zone list, add breadcrumbs and view colours

The view shown in the zone list and on the zone page now links to that
view. The zone page and changeset page get breadcrumbs, and the zone list
keeps its filters in the address so going back restores them. Views can
be given a colour (Views > Edit, `jarl view color`, PUT /views/{id}/color)
so zones of the same view are easy to spot; the colour is UI-only, kept
outside changesets, and needs no deploy.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/api.md

@@ -235,10 +235,20 @@ Responses add `zone`, `view`, `relative_name`, `effective_ttl`, and `text`
 | POST | `/views` | `{"name": "internal", "match_clients": ["homelab", "localhost"], "match_destinations": [], "match_recursive_only": null, "comment": "", "adopt_zones": true}` |
 | GET / PATCH / DELETE | `/views/{id}` | DELETE `?cascade=1` also deletes the view's zones |
 | POST | `/views/order` | `{"ids": [3, 1, 2]}` |
+| PUT | `/views/{id}/color` | `{"color": "green"}`; `""` for the default |
 
 `adopt_zones` moves zones that are not in a view into the new view. named
 requires every zone to be in a view as soon as one view exists.
 
+`color` is how the web UI shows the view: one of `green`, `teal`,
+`purple`, `pink`, `orange`, `yellow`, `red` and `grey`. When it's left out,
+the view uses the link colour. It isn't part of the BIND configuration, so
+`PUT /views/{id}/color` applies at once and creates no changeset. It needs
+write access to the view, and it is logged in the audit log as
+`view.color`. To colour a view that so far exists only in a changeset,
+send the request with that changeset (`?changeset=` or
+`X-Jarl-Changeset`).
+
 ### ACLs and TSIG keys
 
 | Method | Path | Body |