Check roles in OPEN and prevent route leaks with Only to Customer (RFC 9234)

A peer's configured role now does three more things:

- Our OPEN carries the BGP Role capability with what we are to the peer.
  A peer whose own says it is something that does not pair with that, or
  that sends two different roles, is refused with OPEN Message Error /
  Role Mismatch. A peer that says nothing is accepted unless require_role
  is set. A role on a peer in our own AS is a configuration error.
- Routes from a provider, a peer or a route server are marked Only to
  Customer on the way in if they are not already, and our routes are
  marked on the way out to a customer, a peer or a route server client.
- A marked route from a customer or route server client, or from a peer
  with someone else's mark, is a leak and is refused. No policy setting
  turns that off.

The packet crate gains the Only to Customer attribute (malformed:
treat-as-withdraw), and the Role Mismatch subcode is corrected from 8 to
11.

The status page shows whether the peer confirmed its role.

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

bin/bgp/README.md

@@ -94,6 +94,30 @@ the reasons `RPKI invalid` and `ASPA invalid`.
 The connection to the cache is plain TCP, without authentication: run the
 validator on the same host or on a network you trust.
 
+## Roles and route leaks (RFC 9234)
+
+`role` on a peer says what the peer is to us: `PROVIDER`, `CUSTOMER`, `PEER`,
+`ROUTE_SERVER` or `ROUTE_SERVER_CLIENT`. It is not for peers in our own AS.
+With it:
+
+- **The two ends have to agree.** Our OPEN says what we are to the peer (its
+  provider, if it is our customer). A peer whose OPEN says it is something
+  else than configured is refused with OPEN Message Error / Role Mismatch:
+  one side thinking "customer" and the other "peer" is how leaks happen. A
+  peer that says nothing (it does not implement the RFC) is accepted, unless
+  `require_role: true`. The status page shows the role, with a tick when the
+  peer confirmed it.
+- **Routes are marked "only to customer"** (the OTC attribute) when they come
+  in from a provider, a peer or a route server, and when ours go out to a
+  customer, a peer or a route server client. The mark stays on the route.
+- **A marked route coming the wrong way is a leak and is refused**: from a
+  customer or a route server client always, and from a peer unless the peer
+  put the mark there itself. The reason shown is `route leak (Only to
+  Customer)`. No setting turns this off, as the RFC requires.
+
+This catches leaks even where nobody on the path has an ASPA, as long as the
+networks on either side of the leaker mark their routes.
+
 ## AS path verification (ASPA)
 
 Origin validation says who may originate a prefix. It says nothing about the