Retire the legacy thread-task alerting surface once the Recognizer Feedback workflow is migrated

[manerow]

Summary

The alerting layer still carries the pre-redesign thread-task surface: a bridge branch in
AlertUtil, two EventType values reachable only through one legacy workflow, and their message
formatters. None of it can be removed until the last writer of Thread.type=Task is migrated. This
issue tracks that dependency so the rest of the epic is not blocked behind it.

State verified on main (2.0.0-SNAPSHOT, OSS 7cb9ffbb44).

The anchor

CreateRecognizerFeedbackApprovalTaskImpl is the only remaining producer of legacy thread-tasks:

// governance/workflows/elements/nodes/userTask/impl/CreateRecognizerFeedbackApprovalTaskImpl.java:230
.withType(ThreadType.Task)
...
feedRepository.create(thread);

Five of the six user-task implementations already use TaskRepository; this one does not. While it
exists, the legacy PUT /v1/feed/tasks/{id}/resolve|close routes, FeedRepository.resolveTask /
closeTask, and the taskResolved / taskClosed emissions at FeedRepository.java:549,558 are
all live, if narrow.

What this unblocks once the anchor is migrated

Surface	Location	Action
task branch of the thread bridge	AlertUtil.THREAD_TYPE_RESOURCES	remove (the conversation branch stays, it is load-bearing)
taskResolved / taskClosed values	changeEventType.json	retire, closing out the last part of #29039
TASK_RESOLVED / TASK_CLOSED formatters	MessageDecorator.java:408,415	remove or migrate to read Task.status
Legacy thread-task integration tests	FeedResourceIT (22 ThreadType.Task references)	remove with the code they cover

The announcement branch of THREAD_TYPE_RESOURCES is already dead (Announcement is a first-class
entity, rejectLegacyAnnouncementAccess blocks the legacy door) and can be removed at any time,
independently of the anchor. It is small enough to fold into the thread-filter-scoping sub-issue of
this epic.

Scope note

Migrating the Recognizer Feedback workflow itself is a governance-workflows change with an
upgrade-time migration for in-flight approvals, not an alerting change. It is out of scope for this
epic and needs its own issue and owner; this one records the alerting-side cleanup that becomes
possible after it, so the deprecation of taskResolved / taskClosed has a home.

Acceptance criteria

• Owner and issue identified for migrating CreateRecognizerFeedbackApprovalTaskImpl to TaskRepository.
• After that lands: the task bridge branch, both EventType values and their formatters are removed.
• No EventType value remains that only a legacy path emits.