Add Billbee write tools and a DHL Parcel DE Shipping adapter - #1356

Summary

A Cloud user asked to write to Billbee and to create labels on their DHL business account. The Billbee adapter could only read, and the catalog only had DHL tracking. This PR adds write tools to Billbee and a new adapter for DHL's Parcel DE Shipping API.

Changes

• de/billbee.json, 9 new tools. Endpoints and field names come from Billbee's Swagger (app.billbee.io/swagger/docs/v1).
  • Orders:
    • billbee_set_order_state (PUT /orders/{id}/orderstate, with the documented state list)
    • billbee_add_shipment_to_order (stores a tracking number)
    • billbee_add_order_tags
    • billbee_update_order (PATCH, only the fields passed)
    • billbee_create_invoice (Billbee allows one call per order every 5 minutes)
  • Labels: billbee_ship_order_with_label books a label with a carrier connected in Billbee.
  • Stock and products:
    • billbee_update_stock (absolute quantity, by SKU)
    • billbee_list_stocks (needed for multi-stock)
    • billbee_update_product (PATCH)
  • Write tools carry explicit annotations. The instructions gain a "Writing" section.
• de/dhl-parcel-de.json, new: Parcel DE Shipping API v2 (api-eu.dhl.com/parcel/de/shipping/v2).
  • Tools:
    • validate (?validate=true, books nothing, marked read-only)
    • create shipments
    • get labels
    • cancel
    • close out (POST /manifests)
    • get manifest
  • Auth: the Parcel Germany OAuth2 password grant (/parcel/de/account/auth/ropc/v1/token, client_secret_post). It takes the developer.dhl.com API key and secret plus a Geschäftskundenportal user, the same OAUTH2 + grant: password setup as intl/egnyte.json.
  • No dhl-api-key header: the sandbox answers "Use EITHER Bearer Token or (Apikey and Basic Auth)" when both are sent.
  • Instructions explain how the billing number is built (EKP + procedure + participation), the products and services, the 207 partial results, and that each booking is billed by DHL.
• Specs for both adapters, regenerated catalog.ts, quoted counts 679 → 680, and regenerated llms*.txt.

Cloud vs self-hosted: catalog JSON only. Both modes behave the same. Existing Billbee installs see the new tools as a catalog update ("Apply update").

Type

• New feature

Testing

• Added/updated unit tests
• Tested manually

Commands (from the repo root unless noted):

• node scripts/validate-adapters.mjs --warn: no warnings for billbee or dhl-parcel-de (only the existing zucchetti, exact-online and moneybird warnings).
• node scripts/regenerate-catalog.mjs, node scripts/adapter-count.mjs --check (OK, 680), node scripts/generate-llms-txt.mjs --check (OK).
• In packages/backend, npx jest src/adapters: 673 suites passed, 1 skipped.
• In packages/backend, RUN_DHL_PARCEL_DE_LIVE=1 npx jest src/adapters/de/dhl-parcel-de: passed against api-sandbox.dhl.com.
  • The token endpoint accepts the sandbox credentials published in DHL's spec.
  • With that token the shipping endpoint answers 401 "no apiproduct match", not 404: DHL's published sandbox client isn't subscribed to the shipping API.
  • With your own app's DHL_API_KEY/DHL_API_SECRET, the same test validates one shipment.
• No live Billbee write test: it needs a real Billbee account.

Checklist

• My code follows the existing code style
• I have tested my changes locally
• I have updated documentation (adapter instructions)
• All existing tests pass (adapter suites; root npm test is not used, see AGENTS.md)
• This PR has a descriptive title