DWH: Management API: More destination methods added.

[sm-dmitrijus]

What

Adds the last missing Destinations endpoint — batch_update() — completing 8/8 coverage for Item 22a-3.

batch_update(team_id, *, destination_type, updates) rotates secrets for up to 100 destinations of the same type in a single PATCH request. Each update is applied independently; partial failures are reported per item via has_errors and per-item status/error_code/message.

What changed

• Allowlist — PATCH /teams/{team_id}/destinations/batch added to sdk-endpoint-filters.yaml
• Generated code — spec filtered + client regenerated
• Wrapper — batch_update() on both DestinationsResource and DestinationsAsyncResource, following the same batch pattern as transfers.batch_create()
• Raw mirror — batch_update on both with_raw_response classes
• Export — BatchUpdateDestinationsBodyUpdatesItem exported from supermetrics
• Tests — 12 unit tests (success, partial failure, params, 401, 400, 500 × sync/async) + 5 e2e tests over real loopback TCP
• Docs — README, docs/api-reference.md, and HISTORY.md updated

Result

• just qa green (2112 passed, lint clean, typecheck clean, parity 24/24)

[jari-sinkkonen]

Reviewed the hand-written layer (skipped _generated/). Clean, complete, and consistent with the transfers.batch_create() batch pattern. Approving.

Verified against source:

• Wrapper: batch_update() on both sync + async, BatchUpdateDestinationsBody(type_=destination_type, updates=...), unwraps parsed.data to BatchUpdateDestinationsResponse200Data, routes non-200 through _raise_for_status with bad_request_msg. No 404 handling — correct, the batch route has no 404 (same as batch_create).
• Wiring complete: __init__ exports BatchUpdateDestinationsBodyUpdatesItem, _raw.py mirrors on both raw-response classes, allowlist adds PATCH /teams/{team_id}/destinations/batch.
• Docstrings match the generated models exactly — has_errors: bool, results: list[...] with per-item destination_id/status/error_code/message, updates item destination_id: int + new_secret: str. The README and api-reference examples use valid attributes and run (checked after the #86 doc drift — no repeat here), and HISTORY is updated in this same PR.
• Tests: sync unit covers success, partial failure (asserts per-item status/error_code), params-on-the-wire (body.type_, updates), and 401/400/500; async unit has full parity including the 500 case; e2e asserts the PATCH method/path/bearer/body and the partial-failure per-item errors over a real loopback server. just qa green (2112).

Non-blocking nit (optional): the async e2e tests assert a bit less than their sync e2e counterparts — the async success test checks only len(results.results) (not the per-item destination_id/status the sync one checks), and the async e2e lacks the 400 case the sync e2e has. The error taxonomy is fully covered at the unit level for both sync and async, so this is symmetry polish, not a gap. LGTM 🚀