refactor: don't send webhook challenge immediately, allow admin to trigger

[ericfitz]

Why?

Because it might take time for the administrator to take a TMI-server-generated HMAC key to the webhook listener and configure it and restart the listener. This will frequently take longer than our challenge workflow allows.

How?

• maybe add a trigger_challenge boolean field to webhook subscription creation flow; it's nullable, treat not present in request the same as "true".

• if the value is present and set to false in the create request, then require an additional action to trigger the challenge workflow. Maybe allow a specific PATCH against the subscription for this field only to set trigger_challenge to true.

• trigger the actual challenge workflow to start when trigger_challenge is set to true.

The user experience for this in TMI-UX will be that if the user opts to create a delayed-challenge webhook (perhaps implicit- maybe we set trigger_challenge to false if no HMAC value is provided) then the UX will display a "send challenge" button to complete the setup.

Also considered but rejected

We might invert the workflow: a webhook listener could have code to use the REST API to initiate the actual webhook subscription creation and specifically provide a challenge value or get an auto-generated one. This would dramatically simplify webhook setup, but would require the webhook listener to have admin credentials, at least temporarily.

We might revisit this at some time, maybe we ease the permissions required to create webhooks to allow automation accounts to do so, and then either require pre-registration by an admin "this automation account is going to create a webhook subscription, let it", or put the subscription into a hold state until an admin approves.

[ericfitz]

Note to the AI agent: when you implement this work item, ask the user if you should create a tracking issue for TMI-UX to do the UX work.