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.