fix(subscriptions): scope event menu to the destination's supported events

[cl8dep]

Summary

Closes the last open acceptance criterion of #212: the subscription create form now scopes its event menu to the selected destination, so the UI only offers events the destination integration actually handles.

The rest of #212 already landed on main via the RFC 0016 work: the create-time guard in NotificationSubscriptionAppService.ValidateAsync rejects unsupported events, the supported-event set is declared once at the manifest level (IntegrationManifest.SupportedEvents + HandlesEvent with wildcards), and the dead INotificationSubscriber/EventSubscriber declarations were removed. What remained was purely presentational: the event catalog endpoint returned the full closed catalog for every destination, so the form could not scope the menu per integration. This PR carries the supported-event set to the client and filters the menu with the same semantics the backend guard uses, so a user can no longer even select an event the destination would reject at save time.

Related

Closes #212.

Changes

Backend:

• IntegrationTypeMetaDto gains a SupportedEvents field, populated in ToMetaDto() from the manifest. This is the same wire-name set (with wildcards like alert:*) the create-time guard enforces, now surfaced to the client.

Frontend (apps/admin):

• SubscriptionFormModal filters the event menu by the selected destination's supported patterns, mirroring IntegrationManifest.HandlesEvent (*, alert:*, exact match). A Personal destination is unscoped (no per-integration event set), so it still sees the full catalog.
• Already-selected events that a newly chosen destination does not support are pruned, so the form can't submit a selection the backend would reject.
• api-types.ts updated to include supportedEvents. This was hand-edited to match the DTO change rather than regenerated, because pnpm run generate:api-types requires building the API against a live appsettings.Development.json connection string; the edit mirrors exactly what regeneration would emit.

Testing

• dotnet test passes (unit + integration)
• pnpm exec tsc -b passes in affected frontend app(s) (apps/web, apps/admin)
• Manually verified the change end-to-end
• Not applicable (docs/config only)

Ran dotnet build Piro.slnx (0 errors) and the relevant dotnet test filter (subscription / manifest / catalog / integration-type, 75 passed), plus pnpm exec tsc -b in apps/admin (clean). Not yet clicked through in a running browser.

Screenshots

Checklist

• Title follows conventional commits
• Applied all relevant labels
• Docs updated if behavior/config changed (wiki, README, or RFC status)
• No secrets, credentials, or .env/appsettings.*.json values committed