Changelog

A `custom-service` permission request may name the header a pasted token is sent as. Before, a custom service without a browser sign-in could only take `Authorization: Bearer <token>`, so an API keyed by `X-Api-Key` or any other header was out of reach even though `latchkey auth set` stores arbitrary headers. The request payload gains an optional `header`, a header line with `{token}` where the value goes, validated by the same rule as `token-capture`'s `header` plus what the gateway must never let a request set (`Host`, `X-Latchkey-*`), and refused alongside a `login` flow, which carries its own credential shape. The gateway extension and `custom_services.validate_credential_header` share one accept/reject corpus. The header is stored on the service's `registeredServices` entry under `mindsCredentialHeader`, read back by `registration_credential_header`, and `credential_commands.fallback_set_credentials_example` now takes the header. `custom_services.custom_service_credential_header` reads it off a `registeredServices` block by service name, and `credential_commands.set_credentials_example_for` is the one rule every credential form goes through -- the custom-service dialog's, the ordinary permission dialog's, and the Permissions tab's -- so a registration's own header beats the bearer command latchkey reports for every generic registered service, and a token typed into any of them is stored under the header the service actually takes. The payload also gains an optional `credential_instructions`: the agent's plain-text note, at most 500 characters, on where the user finds the credential, for the dialog to show beside the input; it is refused alongside `login` like `header`, and `custom_services.validate_credential_instructions` mirrors the gateway's check, counting characters the same way.