vscode: mark recently-created backlog rows (created within last 24h)

[amrmelsayed]

Problem

The Backlog sidebar tree gives no visual signal when an issue is newly filed. A reviewer scanning the list can't tell at a glance which items just landed versus which have been sitting for days — they have to click into each issue to check createdAt. The Backlog grows daily during active triage; some lightweight "new" indicator would surface fresh items immediately and make first-pass review faster.

Proposal

When a backlog item's createdAt is within the last 24 hours of "now" (re-evaluated on every tree render), render a visual marker on its row. After 24 hours the marker drops off naturally on the next render — no persistent state, no per-user dismissal.

Data is already available: OverviewBacklogItem.createdAt is a required field on the type (packages/types/src/api.ts:225) and is populated through to the VSCode extension via the existing overview pipeline. No data-flow change needed; the entire change is in BacklogProvider's row construction.

Design calls for the implementer

A few small UX picks that should be locked at plan/implementation time, with my proposed defaults:

1. Where to render the marker:

   • (a) Icon prefix — iconPath on the TreeItem, swapped from the default issues icon to a "new" variant when fresh. Cleanest visually; matches how the sidebar already conveys per-row state (account icon vs issues icon based on assignee).
   • (b) Description text suffix — description: 'new' (or '< 1h ago' etc.), shown right-aligned in subdued text. More info-dense but adds noise.
   • (c) Both — icon for at-a-glance, description for precision.
   • Default proposal: (a) icon prefix — minimal noise, fits the existing visual language.

2. Icon choice:

   • $(sparkle) — reads clearly as "new" / "shiny"; commonly used in VSCode for new/AI features.
   • $(star-full) — reads as "important" more than "new".
   • $(circle-filled) (with a color) — reads as a status dot; semantically generic.
   • $(rocket) — too playful.
   • Default proposal: $(sparkle) in ThemeColor('list.highlightForeground') so it picks up the user's accent color and stands out without hand-coded hues.

3. Threshold:

   • Hardcoded 24h vs configurable via setting codev.backlogNewThresholdHours (default 24).
   • Default proposal: hardcoded 24h for v1. Add the setting later only if users ask for it — premature config is its own debt.

4. Tooltip enrichment:

   • The existing row tooltip currently shows protocol/mode/progress (for builders) — backlog rows have their own tooltip shape. The marker rationale ('Created 3h ago') belongs in the tooltip so hovering surfaces precision without cluttering the row.
   • Default proposal: append Created <relativeTime(createdAt)> to the existing backlog row tooltip whenever createdAt is present, regardless of whether the row is marked as new. Useful info even after the 24h window passes.

5. Interaction with the mine-only toggle (vscode: backlog view — toggle between 'mine only' (default) and 'all' #809):

   • Items hidden by the mine-only filter are not rendered at all, so the marker question doesn't arise for them. No special handling needed — confirm there's no edge case in BacklogProvider.orderedSpawnable that would change this.

Acceptance

• Backlog rows whose createdAt is within the last 24 hours render with the chosen marker (icon prefix per default proposal).
• Older rows render unchanged.
• The 24h evaluation uses "now" at render time — items aging past the threshold lose the marker on the next refresh, with no further action.
• Tooltip on every row with a createdAt includes Created <relativeTime> (e.g. Created 3h ago, Created 2d ago).
• No regression to the mine-only toggle (vscode: backlog view — toggle between 'mine only' (default) and 'all' #809), area grouping (vscode: group backlog by area (area/* label namespace, predictable across views) #811), or the title-count formatter (vscode: Backlog tree title-count should reflect the active view mode, not the total spawnable set #911) — all still render correctly with the marker present.
• No regression when createdAt is missing or malformed (fallback: row renders without the marker, no thrown error).

Out of scope

• Persistent per-user "mark as seen" state — the 24h window is a pure age threshold, not a read/unread state machine.
• Sorting changes — newly-created items don't get re-sorted to the top; they appear in the existing order with a marker.
• Notifications, toasts, or activity-bar badges for new items — separate enhancement if desired.
• Backlog tree polling cadence changes — relies on the existing refresh schedule; the marker just reflects createdAt as the data refreshes.

Why AIR

Data is already on the type; change is confined to packages/vscode/src/views/backlog.ts row construction (and possibly a small helper for the age computation if it doesn't fit inline). Sub-50 LOC, no architectural decisions, no design ambiguity left after this issue body. The five design calls above are concrete enough that one builder pass + one consultation can lock them in.

[amrmelsayed]

On it! Working on this with the PIR protocol (plan + dev-approval gates before PR).