Changelog

The custom-service approval dialog shows, behind a collapsed "How this will be sent" disclosure, the header every request to the service will carry the pasted token in, so a user asked for an `X-Api-Key` can check it against the provider's docs. The desktop registers the header a request names (`payload.header`), shows the existing registration's header for a service this computer already has, and stores the token the user types under that header rather than as a bearer, whatever latchkey's generic credential example says. A request with no header keeps the bearer default; a browser sign-in shows no disclosure. The Permissions tab and the ordinary permission dialog (the one a re-auth or a service with no stored credential goes through) read the same header off the registration, so a token typed into either for such a service is stored under it too. The credential form also shows the agent's note on where to find the token (`payload.credential_instructions`), under "From the agent" and as plain text, between Mind's own instruction and the input, and keeps it up after a rejected attempt. And the form's first appearance, in answer to the Approve that registers the service, now reads as an instruction rather than a red error notice; only an attempt that sent a token and was rejected shows as a failure.