VOIP-1304-Redact-marshaled-response-body-from-debug-logs

[pchero]

Stop bin-customer-manager/pkg/listenhandler from logging full marshaled RPC response bodies at DEBUG level, which leaked Customer.WebhookSecret (reusable HMAC signing secret) and, on the Signup endpoint specifically, a freshly-issued Accesskey.RawToken (one-time plaintext bearer token) alongside it. Follow-up to VOIP-1291/PR #1171, which fixed a different logging pattern (WithField("customer"/"accesskey", )) in the same package but left this one (json.Marshal(tmp); log.Debugf("Sending result: %v", data)) unaddressed.

• bin-customer-manager: Fix 18 sites across v1_customers.go (9), v1_customers_signup.go (2), v1_customers_freeze.go (3), and v1_accesskeys.go (4) -- both the marshal-error-path log (which also referenced the full struct/data) and the success-path log now emit only an ID (or count for List endpoints, or the pre-existing expired/processed int for the two cleanup endpoints that never carried a secret to begin with). Signup logs both customer_id and accesskey_id since it provisions both resources. Of the 18 sites, 12 were genuine secret leaks (7 in v1_customers.go, 3 in v1_customers_freeze.go, 2 in v1_customers_signup.go); the other 6 (customer cleanup endpoints, accesskey List/Get/Delete/Put) carried no live secret but shared the same log-the-marshaled-body anti-pattern.
• bin-customer-manager: Fix a pre-existing test-fixture bug found during implementation -- Test_processV1CustomersSignupPost's mock left SignupResult.Accesskey nil, which the old code never touched but the new tmp.Accesskey.ID logging dereferences. Production's customerHandler.Signup always auto-provisions an accesskey, so the fixture now reflects that invariant with a realistic Accesskey and a correspondingly updated expected response JSON.

The accesskey creation endpoint (processV1AccesskeysPost) was already fixed in VOIP-1291 and is untouched here.

Verification: full 5-step workflow (go mod tidy/vendor/generate/test/lint) passing in bin-customer-manager. Confirmed the actual API response body (sock.Response.Data) is byte-identical to before this change in every touched function -- only the debug-log statements were modified.