refactor: split buspro ApiClient into domain clients

docs/buspronet-schema/crm-selection-queries.md

@@ -9,7 +9,7 @@ Companion to `travel-queries.md` (static catalog) and `live-api-queries.md` (liv
 socket endpoints). This one covers the `KUNDENKONTO` / `art=SelektionCRM` response —
 the document that drives the portal's entire authorization model.
 
-Request side: `ApiClient::getCrmAttributes()` (`src/BusProNet/ApiClient.php`) sends
+Request side: `AccountClient::getCrmAttributes()` (`src/BusProNet/Client/AccountClient.php`) sends
 `satz typ="KUNDENKONTO"` + `art=SelektionCRM` + the customer's email/password.
 Response side: `CrmAttributesResponseParser`
 (`src/BusProNet/XmlParser/CrmAttributesResponseParser.php`) turns selection ids into
@@ -229,7 +229,7 @@ Three conclusions:
 `dbo.AgenturSelektionenKunde` is a bare two-column link table,
 `(IDAdresse_FS, IDSelektionsstamm_FS)` — literally *"agency's customer selections"*. The
 portal authenticates against BusPro as an **agency** account (`bpn_username` in
-`ApiClient`), so a per-agency whitelist of which customer selections that agency may see
+`XmlChannel`), so a per-agency whitelist of which customer selections that agency may see
 and/or edit is exactly the right shape. It is the only candidate found so far that could
 explain the `1478` omission **and** `aenderbar` through one mechanism.
 
@@ -461,7 +461,7 @@ and they are long shots. Prefer the escalation path below.
 Escalation path, cheapest first:
 
 1. **Re-fetch and confirm staleness.** Our side does not cache this call — the
-   `xml-sync` cache tag covers the XML *export* sync, and `ApiClient::getCrmAttributes()`
+   `xml-sync` cache tag covers the XML *export* sync, and `AccountClient::getCrmAttributes()`
    has no cache layer — so a fresh login hits BusPro directly. If `1478` is still absent
    from a response captured after the insert, the staleness is on the BusProNet host and
    an application-pool/service restart there is the test.

docs/buspronet-schema/live-api-queries.md

@@ -5,8 +5,8 @@
 > per-endpoint migration verdicts and the `frei` discovery SQL.
 
 This complements `travel-queries.md`. That doc replaced the **XML export** (static
-catalog). This one covers the **live socket API** methods on
-`src/BusProNet/ApiClient.php` and classifies how replicable each is by direct MSSQL
+catalog). This one covers the **live socket API** methods of the clients in
+`src/BusProNet/Client/` and classifies how replicable each is by direct MSSQL
 query in the Go proxy.
 
 **Verdict in one line:** the *structural* parts replicate cleanly; the *live "free"