status_notifications.reaction config has no forge-compatibility validation

[ralphbean]

What happens

validateStatusNotifications (internal/config/config.go) only checks that comment/reaction start/completion values are one of the allowed strings (enabled/disabled/on_failure). It has no awareness of which forge the config applies to.

If a repo on GitLab sets status_notifications.reaction.start: enabled (or completion), config parsing succeeds, but every reaction call at runtime hits forge.ErrNotSupported — GitLab's AddIssueReaction/DeleteIssueReaction/AddIssueCommentReaction/DeleteIssueCommentReaction (internal/forge/gitlab/issue.go) all return it unconditionally. Notifier.addReaction/deleteReaction (internal/statuscomment/statuscomment.go) fail open on that error — they log a warning via n.warnf and continue, so nothing ever reaches the user. The config looks valid and the run succeeds; reactions just silently never appear.

What should happen

A user enabling reaction notifications on a forge that doesn't support them should get some signal that the setting is inert — today they only find out by reasoning about the code or a log they aren't watching.

Context

Surfaced during review of #5957 (waynesun09), which introduced status_notifications.reaction and documented GitLab's ErrNotSupported behavior. Filed as a follow-up because fixing it well needs a forge-capability query at config-validation time, more design than fits in that PR.

Scoped to the confirmed GitLab gap; not asserting the same applies to JIRA — its current client (internal/forge/jira) is a polling input driver, not a forge.Client reaction target.

[fullsend-ai-prioritize]

RICE Priority Score: 0.13

Score breakdown

Dimension	Score	Reasoning
Reach	0.5	This affects only GitLab users who attempt to enable the reaction notification feature introduced in #5957. It is a subset of GitLab users configuring a specific, newer feature — not a platform-wide concern.
Impact	0.5	The silent failure is confusing but not blocking. Workaround is trivial: don't enable reaction notifications on GitLab. No data loss or workflow breakage occurs — reactions just silently never appear, and the run still succeeds.
Confidence	0.8	The issue is exceptionally well-described with specific code paths (validateStatusNotifications, forge/gitlab/issue.go, statuscomment.go), clear scope limited to GitLab, and an explicit non-assertion about JIRA. The fix direction (forge-capability query at validation time) is identified but acknowledged as needing design.
Effort	1.5	Requires introducing a forge-capability query interface so config validation can check whether the target forge supports reactions. This touches the forge interface layer, at least the GitLab implementation, and the config validation logic — multiple components with some design work needed, as noted by the author.

Formula: (0.5 x 0.5 x 0.8) / 1.5 = 0.13