hive-c0re, docs: sweep remaining stale ask/answer-dashboard references

docs/boundary.md

@@ -28,14 +28,12 @@ always on), the gateway proxies all operator-facing traffic, and
 **Operator-authority actions never get a per-agent-socket entry
 point.** They live on the core backend.
 
-Worked example — answering an operator-targeted question is a
-`POST /api/answer-question/{id}` on the core dashboard, _never_ a
+Worked example — destroying or rebuilding a container is a
+`POST /api/{destroy,rebuild}/{name}` on the core dashboard, _never_ a
 per-agent-socket `Request` variant. If it were a per-agent-socket
-request, an agent could `curl` its own socket and spoof an operator
-answer.
-The per-agent web UI POSTs cross-origin to the core for these
-(see the inline-answer feature — the loose-ends section on each
-agent page).
+request, a compromised agent could `curl` its own socket and destroy
+or rebuild itself (or, if the variant took an arbitrary target, another
+agent) without ever touching the core's own authenticated surface.
 
 ## Why network isolation is the load-bearing step
 
@@ -67,9 +65,10 @@ The boundary rests on three layers:
 
 1. **Gateway** — fronts all surfaces (dashboard + every per-agent UI)
    on one origin. An nginx nixos-container proxies per-agent UIs under
-   `/agent/<name>/`, which is what lets the inline-answer POST to
-   `/answer-question/{id}` go same-origin instead of needing a
-   cross-origin CORS shim. Pure ergonomics — no behavioural risk on
+   `/agent/<name>/`, which is what lets each agent page's inbox panel
+   POST `mark-all-read` to the core dashboard's
+   `/api/agent/{name}/mark-all-read` go same-origin instead of needing
+   a cross-origin CORS shim. Pure ergonomics — no behavioural risk on
    its own.
 2. **Network isolation** — the load-bearing layer: every agent
    container runs in a private netns behind the hive bridge, always