Surface repeated activity retry failures in TemporalReportedProblems

Is your feature request related to a problem? Please describe.

Temporal already surfaces consecutive workflow task failures through TemporalReportedProblems, which gives operators a low-cardinality visibility signal for executions that are still open but likely need attention.

Activity retry loops can create a similar operational state: an execution is still alive, but one or more activities are repeatedly failing or timing out and the workflow is not making useful progress. Today this can be diagnosed by inspecting workflow history or mutable execution details, but it is not available as a small visibility-level signal that operators can query.

Describe the solution you'd like

Extend the existing reported-problems mechanism to optionally include repeated activity task retry problems.

A possible v1 shape:

• Add a namespace dynamic config threshold for consecutive activity task problems, defaulting to disabled.
• When a pending activity reaches the threshold, upsert bounded tokens into the existing TemporalReportedProblems search attribute.
• Keep tokens low-cardinality, for example:
  • category=ActivityTaskFailed
  • cause=ApplicationFailure
  • category=ActivityTaskTimedOut
  • cause=ActivityTaskTimedOutCauseStartToClose
• Clear the activity-side signal when the activity succeeds, is canceled, reset/unpaused, or no pending activity still qualifies.
• Prefer deriving the signal from mutable state/history state, not storing raw error messages or activity IDs in visibility.

Describe alternatives you've considered

• Status quo: operators inspect individual workflow history or describe output when they suspect an activity retry loop.
• Add a separate search attribute for activity problems. This is more explicit but would require new visibility schema/search-attribute surface.
• Store raw activity failure messages or activity IDs in visibility. This would be more detailed but has cardinality and privacy concerns.
• Emit only metrics/logs. This helps aggregate monitoring but does not let operators query affected executions directly.

Additional context

This would reuse the existing TemporalReportedProblems operator UX rather than adding a new public API or proto surface. The first version could be default-off behind dynamic config and scoped to low-cardinality activity retry evidence only.

I have a local spike and tests for this shape and can open a small PR if maintainers agree this direction fits the reported-problems model.