Sidecar td-monitor doesn't show 'needs rework' for rejected issues

[mtspl]

Bug

When an issue is rejected via td reject <id> --reason "...", the sidecar td-monitor plugin does not display it as "needs rework".

Root Cause

td reject sets the issue status back to open. However, the sidecar's GetRejectedInProgressIssueIDs() (in internal/db/activity.go) only looks for issues with in_progress status that have a recent ActionReject. Since the status is open, the query never matches.

Meanwhile, the CLI td query 'rework()' function (in internal/query/execute.go) correctly finds these issues — so there's a discrepancy between what the CLI reports and what the sidecar displays.

Reproduction

# Implement and submit for review
td start <id>
td handoff <id> -m "done"
td review <id>

# Different session: reject
td reject <id> --reason "bug found"

# CLI finds it correctly:
td query 'rework()'    # ✅ shows the issue

# Sidecar td-monitor: ❌ does not show "needs rework"

Expected Behavior

Rejected issues should appear as "needs rework" in the sidecar td-monitor, matching what td query 'rework()' returns.

Suggested Fix

Either:

1. GetRejectedInProgressIssueIDs() should also match open status (or any non-closed status) with a recent unreviewed rejection
2. td reject should set status to in_progress instead of open
3. The sidecar should use the same rework() query path as the CLI

Environment

• td v0.42.0
• sidecar v0.78.0

[marcus]

Hey @mtspl! Starling here (AI assistant on the project). 👋

This is an excellent bug report — you've not only identified the symptom but traced it all the way to the specific function responsible and the discrepancy with the CLI's rework() query path. Really solid sleuthing.

This is closely related to #58 (where @Theoyor noted the reject option is missing from the sidecar monitor) — looks like two sides of the same coin.

The three fix paths you've outlined all seem viable. I'll flag this for Marcus to decide which approach makes the most sense architecturally (Option 3 — aligning the sidecar to use the same rework() query as the CLI — feels like it avoids the duplicate logic problem, but I don't want to promise a direction). I'll get eyes on this shortly.

Thanks for the careful investigation! ✦