Integrations: one Connector record for a party in either direction and one inbound receiver primitive

An outside party is modelled differently in each direction and each receiver verifies itself. The Webhook action takes `Url` and `Secret` as parameters (`barakoCMS/Features/Workflows/Actions/WebhookAction.cs:29-30`), while `Connector` (`barakoCMS/Features/Connectors/Models.cs`) is used by the Request action only. `BarakoCMS.Email.Resend/ResendWebhookEndpoint.cs:55` and `:129-139` implement their own Svix signature and timestamp check. #838 plans its own payment receiver, and #831 and #833 each add a way to register a party.

### Why it matters

A clinic's payment provider both receives calls from the API and sends webhooks back. Today that is a connector for one direction, a hand-written endpoint for the other, and a second copy of signature checking, replay window and dedupe for each provider. Each copy is a place to get verification wrong.

### The general concept

One Connector record per outside party, usable for outbound calls and inbound webhooks. One receiver primitive: verify the signature by a named scheme (HMAC, Svix and so on), refuse outside a replay window, dedupe by the provider's event id, acknowledge, then hand the payload to a job. Resend, payments and #831 results all use it. #690 explored receiving and closed without an answer.

### Where it lives

Core: connectors and a receiver endpoint. Modules (Email.Resend, Payments) register their scheme and handler.

### Compatibility

Released parts keep working: the Webhook action's parameters stay valid, and the Resend endpoint keeps its route while moving onto the primitive. The receiver is new. Connector gains an inbound section, which is an additive change to its stored document.

### Done when

- The Resend webhook is verified by the shared receiver, and its existing tests pass.
- A replayed event with the same provider id is acknowledged and not processed twice, and a test showing that is not guarded generically today.
- A Webhook action can name a Connector instead of a raw URL and secret.

Found in the architecture sweep of 15 September 2026.

Start with barakoCMS/Features/Connectors/Models.cs and WebhookAction.cs:29-30, then inspect BarakoCMS.Email.Resend/ResendWebhookEndpoint.cs:55 and :129-139 and its existing tests. Trace how the current Resend verification and Webhook action are wired. Done means Resend uses the shared receiver, replayed provider events are acknowledged without duplicate processing, and Webhook can reference a Connector while existing behavior and tests remain valid.

Written by the indexing model from the issue text.