test(bbm): assert graceful degradation in the live-API tests

[timrabl]

Addresses the actionable part of #36. (The upstream outage itself isn't fixable by us — #36 stays open to track it.)

Problem

The #[ignore]d live-API tests .unwrap()'d a success, so they panicked whenever an upstream endpoint was down. Several breitbandmessung.de endpoints currently are — they return HTTP 200 with an HTML error page:

/api/speed        → Table 'fixedspeed' doesn't exist in database
/api/provider/{id} → SQLSTATE[42S22]: Unknown column 'fixedoperator.topten'
/api/speed/{id}   → SQLSTATE[42000]: ... not in GROUP BY clause

So cargo test -- --ignored panicked on three tests, testing upstream uptime rather than our own behaviour.

Change

The tests now assert the library's contract, not upstream availability: a call either parses, or fails with a clean typed error — and must never surface as BbmError::Json, which would mean a non-JSON body reached the deserializer (the panic path #24 fixed). Happy-path validation still runs when an endpoint is up.

A shared assert_graceful helper in testutil captures this.

Verified against the live API

All five pass today, with three endpoints broken:

test speed::tests::test_get_speeds ... ok
test provider::tests::test_get_provider_by_id ... ok
test plan::tests::test_get_plans_by_provider_id ... ok
...
degraded gracefully: API error: /api/speed returned non-JSON response
  (Content-Type: text/html): Table 'fixedspeed' doesn't exist...

The broken endpoints return BbmError::Api and degrade gracefully; the working ones (provider list, plans) validate their data.

cargo test --workspace → 114 passed · cargo test -- --ignored → 5 passed · clippy -D warnings → 0 · fmt --check clean