policy, config, web: the TCP gauges named once, one revalidator, one peer-naming rule

A code-quality pass over policy, configuration and the status API.
The twenty TCP gauges were spelled out in the struct, the
constructor, the removal, the sampler in the web crate and the status
view; one macro names each once with its help text, `PeerTcp::set`
fills them from a connection, and the view is a `From`. Every metric
and the list that forces them at start come from one declaration,
with a test that every declared family is registered. The two
revalidators, for next hops and for RPKI, share the task body that
scans the table off the sessions' threads and fans the findings out
to every session; the RPKI scan judges a route with the same `Checks`
the import path uses. Which peer a query names is one rule for the
received, rejected and TCP endpoints, so `/api/tcp` takes a name or an
address like the others. The config parser says proto3's "zero is
unset" in three helpers instead of a dozen shapes, and `parse_peer`
is three named parts shorter. The policy's test-only next-hop flag is
named for what it does, `accept_own_host_next_hop`; the "listed, or
else ours" prefix rule and the mark-then-prefer step each exist once.
The status page derives its spanning rows from the table's header,
shares one key-value grid and one detail-row rule, and defines its
helpers before their use. The web crate no longer re-exports views
nothing uses, and the TCP endpoint sits above the test module.

Testing: the TCP view's arithmetic (a share of no busy time is zero,
not NaN), the peer-naming rule, the RPKI scan finding only what a
change can have made invalid, and `/api/tcp` by address, by name and
for an unknown peer. The server and web tests, the HTTP, roles, RPKI
and import-policy integration tests, the docs build and every lab
phase pass.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/content/docs/reference/http-api.md

@@ -233,9 +233,11 @@ routes. To return the records for one neighbor, add `?peer=NAME`.
 
 ## TCP Connection
 
-`/api/tcp?peer=ADDRESS` returns what the kernel reports about the TCP
-connection of the session with the neighbor at `ADDRESS`, given as
-`peer_addr` in `/api/peers` shows it: the round-trip time, the congestion
+`/api/tcp?peer=PEER` returns what the kernel reports about the TCP
+connection of the session with the neighbor `PEER`, named as for
+`/api/routes/received`: its configured name, or its address, with or
+without the port as `peer_addr` in `/api/peers` shows it. The report
+covers the round-trip time, the congestion
 and receive windows, the queues, the retransmissions, and how long the
 connection has been held up by the neighbor's receive window or by the
 local send buffer. Linux only; on other systems, and for a session the