Surface skipped webhook presets to the user when a trigger is swapped

[linear-code]

Why

Follow-up to #13385 / PR #13394, which made webhook-preset version migration trigger-compatibility-aware. When a user activates a new graph version whose trigger block differs from the one a preset's webhook was registered for, the preset is intentionally left pinned to its old version (so its existing webhook keeps working) rather than silently migrated into a broken state.

Today the only signal that this happened is a server-side logger.warning in migrate_webhook_presets_to_new_version (backend/api/features/library/db.py). Users who swap their agent's trigger (e.g. Telegram → GitHub, or GitHub "on PR" → "on issue") get no UI notification that some presets were left behind and need reconfiguration — and they won't check server logs.

Raised by autogpt-pr-reviewer on PR #13394 and deferred as out of scope for that backend-correctness fix.

What

Surface skipped/incompatible presets to the user so they know to reconfigure the trigger on the new version.

How (possible approaches)

• Have migrate_webhook_presets_to_new_version return the list of skipped preset IDs (instead of just a count) so the API/activation layer can act on it.
• On graph activation, send a user notification (e.g. via the notification server) and/or include skipped-preset info in the activation response.
• Optionally flag affected presets in the Library UI as "trigger needs reconfiguration."

Notes

• Scope is product/frontend + a small backend signal change; no change to the correctness behavior shipped in fix(backend): webhook preset version migration ignores trigger-block compatibility #13385.
• Low priority — the existing behavior is safe (presets keep working on their pinned version); this is purely a discoverability/UX improvement.