Code health after review: docs, metrics, structure, one more fuzz target

What the code-health review found, and what a fuzz target written for it
found in its first seconds.

- A set of attributes with the same attribute twice is refused by the
  routing table. Its readers (the selection key, the path, the next hop)
  could each take a different one of the two. The decoder never lets one
  through; the new fuzz target `attrs` found that the table would.
- bgp_peer_up{peer}, to alert on a peer going away, and bgp_build_info.
  Every metric is there from the first scrape. Alerts for a peer down,
  hijack attempts and kernel errors are in the README.
- `bgp --check config` validates a configuration without starting, and
  `--version` says which build it is. CI runs the first on the example
  configuration, which a test now also parses with its commented fields
  put in; the example had to learn about the next hop check.
- Path attributes have a module of their own, packet::attributes,
  re-exported from packet::message as before.
- policy::From, which shadowed the trait, is RouteSource. The server's
  connection, dialer and fsm modules are private. Logging arguments live
  in the binary; the server library no longer depends on clap.
- One is_unicast_link_local (the standard library's) instead of two of
  our own; SelectionKey::origin(); one place where an Import is made.
- READMEs say what the daemon does today rather than what it did not do
  a year ago. Documentation links are checked in CI. Unused dependencies
  and bgp_web::serve are gone; the Docker build is --locked and does not
  ship the fuzz corpus.

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

bin/bgp/README.md

@@ -7,6 +7,10 @@ daemon together with its read-only HTTP status interface.
 cargo run -- path/to/config.textpb
 ```
 
+`--check` reads the configuration, says whether it is in order, and stops
+without listening on anything or touching a route: for trying a change
+before the daemon is restarted with it.
+
 The configuration format is defined in `crates/server/proto/config.proto`;
 `testdata/server.textpb` is a worked example. The daemon is configured
 entirely through that file: peers, and the routes it originates
@@ -403,6 +407,8 @@ For alerting, `/metricz` has:
 | `bgp_peer_max_prefixes{peer}` | The peer's limit, where it has one |
 | `bgp_prefix_limit_exceeded_total{peer}` | Sessions ended for going over the limit |
 | `bgp_connections_refused_total{reason}` | Connections closed without a session |
+| `bgp_peer_up{peer}` | 1 while the session with a configured peer is Established, else 0 |
+| `bgp_build_info{version}` | Always 1; says which version is running |
 
 Rules to start from:
 
@@ -429,6 +435,20 @@ groups:
       - alert: BgpPrefixLimitExceeded
         expr: increase(bgp_prefix_limit_exceeded_total[1h]) > 0
         labels: { severity: page }
+      # A configured peer has no session.
+      - alert: BgpPeerDown
+        expr: bgp_peer_up == 0
+        for: 5m
+        labels: { severity: page }
+      # Someone is trying to have our own prefixes, or our traffic, go
+      # where they should not.
+      - alert: BgpHijackAttempt
+        expr: increase(bgp_routes_rejected_total{reason=~"prefix is our own|next hop is not the peer"}[10m]) > 0
+        labels: { severity: page }
+      # The kernel is refusing routes, or its answers are being lost.
+      - alert: BgpKernelErrors
+        expr: increase(bgp_kernel_errors_total[10m]) > 0
+        labels: { severity: warning }
 ```
 
 ## Trying it without a router
@@ -445,9 +465,3 @@ cargo run -- testdata/server.textpb
 cargo run -p bgp-integration-tests --example fake_peer -- \
     --server 127.0.0.1:179 --asn 65001 --announce 203.0.113.0/24 --echo
 ```
-
-Please refer to the other implementation crates in this repository where most
-of the actual implementation lives.
-
-Warning: This is still very much a work in progress and is not yet ready for
-production use.