debug network-info: observed_addresses reports announced addresses, not observed ones

The issue is in internal/node/debug_handlers.go lines 241-244, where observed_addresses is populated from Host.Addrs(). Check the libp2p host interface for a method to get actual observed addresses from peers. Update the field name to announced_addresses and references in SKILL.md and tests/integration/debug_endpoints_test.go. Run the debug endpoint test to verify the change.

Problem

GET /debug/network-info (sam-node debug network-info) returns two lists.
The second one, observed_addresses, is filled from Host.Addrs()
(internal/node/debug_handlers.go:241-244). That is the set of addresses this
node announces: its listen addresses expanded to each local interface,
run through announceFilter (internal/node/node.go:2219), plus relay
circuit addresses. The node works these out from its own network interfaces.
None of them were observed by another peer.

Example from a laptop node joined to a sam-one on Cloud Run:

"observed_addresses": [
  "/ip4/10.44.0.7/tcp/41873",
  "/ip4/172.30.5.1/tcp/41873",
  "/ip4/10.99.12.1/tcp/41873",
  "/ip4/172.18.200.1/tcp/41873",
  "/dns4/<sam-one-host>/tcp/443/wss/p2p/<router-id>/p2p-circuit"
]

The four private entries are the laptop's own network interfaces (LAN and
VM/container bridges). In libp2p, an "observed address" means something else:
the address a remote peer saw a connection come from, reported back through
the identify protocol. For a node behind NAT that is its router's public IP
and port, which the node cannot learn by itself.

The mix-up matters when diagnosing NAT traversal. "Which address did the mesh
see me at?" is exactly the question the field appears to answer, and
agents/skills/sam-mesh/SKILL.md:121 describes the command as showing
"listen and observed addresses".

Proposal

1. Rename the current field to announced_addresses, since that is what it
   holds. Update the SKILL.md line and
   tests/integration/debug_endpoints_test.go:168.

2. Optional: add a real observed_addresses list with the addresses peers
   reported seeing this node at. It shows whether the mesh can reach the node
   directly:

   • A public address listed: other peers can try to connect straight to the
     node, and hole punching has an address to work with.
   • Empty: no peer ever saw a public address for this node. Direct
     connections cannot be set up, and all incoming traffic has to go
     through the relay.

   Only worth doing if go-libp2p exposes these addresses through a public
   API.