Add band number activate/deactivate for service-activation orders

[kshahbw]

Summary

Adds verb-style commands to flip per-number voice/messaging activation flags via the Universal Platform's serviceActivation endpoint:

band number activate <num...> --voice-inbound [--wait]
band number deactivate <num...> --voice-inbound

This closes a gap in the existing voice-provisioning workflow. After vcp assign, an inbound call to a fresh number didn't actually route to your app — inboundActivated defaults to false on new numbers and the only way to flip it was the dashboard. With this PR the auth → app → vcp → number → vcp assign → call chain extends to … → number activate → call, fully programmable.

Why a verb pair, not band number set

The underlying API resource is genuinely an async order (with orderId, orderStatus, polling), not a property mutation:

• Matches the existing --wait pattern (number order, call create, transcription create).
• Verbs are unambiguous in shell history and CI logs vs. flag-driven mode-switching — friendlier for agents per AGENTS.md.
• Slots cleanly into the workflow diagrams already in AGENTS.md and README.

API surface

All Universal Platform, all documented at https://dev.bandwidth.com/docs/universal-platform/service-activation:

Endpoint	Used for
POST /api/v2/accounts/{id}/serviceActivation	Create the activate/deactivate order
POST /api/v2/accounts/{id}/serviceActivationChecker	--dry-run eligibility matrix
GET /api/v2/accounts/{id}/serviceActivation/{orderId}	--wait polling

Service flags map directly to the documented values:

• --voice-inbound → services.voice = ["INBOUND"]
• --voice-outbound-national → ["OUTBOUND_NATIONAL"]
• --voice-outbound-international → ["OUTBOUND_INTERNATIONAL"]
• --messaging → services.messaging = ["ALL"]

Plus --customer-order-id for traceability and --timeout (default 60s) for --wait.

Test plan

• Unit tests for BuildServiceActivationBody (voice-only, all-services, voice+messaging, deactivate action, missing-services validation, customerOrderId passthrough) and BuildCheckerBody. 7 new tests, no existing tests touched.
• Live API round-trip against a real account:
  1. --dry-run → checker returned the IN_SERVICE matrix
  2. deactivate ... --voice-inbound --wait → order polled RECEIVED → COMPLETE; inboundActivated flipped true → false; outbound flags untouched
  3. activate ... --voice-inbound --wait → flipped back to true
• go build ./... clean
• go test ./cmd/number/... all green

Docs

• README.md: new rows in the band number command table; usage-example block updated
• AGENTS.md:
  • Both Universal Platform workflow diagrams updated (top-level overview + provisioning walkthrough)
  • New step 7 in the walkthrough
  • New row in the timeout-recovery table

Things to scrutinize

1. Three files (activate.go + deactivate.go + service_activation.go shared) vs one combined file. The 90% shared logic argued for splitting; the codebase's one-file-per-command norm could argue for combining. Happy to consolidate if preferred.
2. No --if-not-exists. AGENTS.md says creates should support it; activation orders are technically creates. I left it out for v1 because "is service X already active" requires an extra serviceActivationChecker call and meaningful state comparison. Reasonable v1.1 follow-up.
3. No proactive auth status capability check. Following the fast-fail-from-API pattern that vcp update and other write commands use.

[bwappsec]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.