feature: show every external destination the agent reaches — URL-level egress visibility

Feature Description

Today abctl observe shows model calls, tool calls and A2A messages well, but a user cannot
answer the simplest trust question about their agent: what is it talking to? The host column
is truncated (api.us-east.bob.ibm…), non-LLM traffic carries little detail, and CONNECT
tunnels show as tunnel with no path at all.

@maia-iyer's framing: users want to see all the external calls the agent makes in the
background — not just the ones Cortex parses as interesting. An agent that quietly fetches from
a domain nobody expected is exactly the thing an observability tool should surface first.

Proposed Solution

• A destination-oriented view in abctl: one row per host, with call count, bytes,
  first/last seen, and whether Cortex parsed the body or only saw a tunnel
• Full URL (scheme, host, path, method) recorded per request; the TUI shows the untruncated
  value on selection even when the column is narrow
• Distinguish clearly between parsed (TLS-terminated, body understood), seen
  (metadata only) and opaque (CONNECT tunnel, host from SNI only) — do not let "we
  couldn't read it" look like "nothing happened". Builds on #906
• Query strings recorded but redacted by default — they carry tokens and API keys
• Per-session, so "what did this agent run reach" is answerable, and available on
  /v1/sessions/{} for non-TUI consumers
• Group by registrable domain as well as exact host, so 40 CDN shards read as one entry

Additional Context

Credit: @maia-iyer — team brainstorming, September 2026. Post-v0.9.0; the release is judged on
the token and cost numbers being correct, and this adds a new surface rather than fixing one.

Related: #906 (better information for non-LLM/A2A/MCP traffic) is the narrower prerequisite —
method and path on the wire. This issue is the view built on it. #724 (surfacing outbound
pipeline denials) is the enforcement counterpart: this issue says what was reached, #724 says
what was blocked. The README already lists egress control as a platform capability, so the data
model should be shared with it rather than invented here.

Part of the post-v0.9.0 brainstorm backlog under #962.

Start with abctl observe, the /v1/sessions/{} surface, and prerequisite issue #906; review how the README describes egress control and how #724 models outbound denials. Done means a per-session destination view with full URL details, parsed/seen/opaque status, redacted queries, domain grouping, and the listed counts and timestamps for both TUI and API consumers.