fix(list): stop repeating the failure count in the list footer

[max-sixty]

Follow-up to #3442. A failed task printed the same count twice on adjacent lines — the summary footer's N tasks failed clause and the ▲ N tasks failed: warning header directly below it that names each failure:

○ Showing 5 worktrees, 3 ahead; 6 tasks failed
▲ 6 tasks failed:
  (detached): working-tree conflict check
    fatal: bad object HEAD

The footer clause was never a distinct signal: its count is exactly non_timeout_errors.len(), and that vector being non-empty is precisely the condition under which the warning renders. So the number was duplicated in 100% of cases.

Rather than suppress the duplicate when a warning happens to follow, this splits the two by what each reports. The footer counts what's missing from the table — timed-out tasks, which leave an empty cell and have no message to print, so a count is the only signal they can carry (and the warning deliberately filters them out). Failures are named in the warning with git's full error text. format_summary_message drops its error_count parameter entirely; the footer now reads:

○ Showing 5 worktrees, 3 ahead
▲ 6 tasks failed:
  ...

Also corrects a stale claim in the status_symbols module spec: it said the footer "lists which tasks did not finish per item," giving a mapping from a · cell back to the timed-out TaskKind. No such mapping ever existed — the footer only carried counts, and budget-based truncation produces no diagnostic at all by design.

One narrow behavior note: in progressive TTY mode the footer is stdout (a repainted table row) while the warning is stderr, so wt list 2>/dev/null on a TTY no longer shows a bare failure count. That case was already discarding the error detail, and discarding stderr discards narration by definition; the ordinary piped case (both on stderr) is unchanged.

Testing

The format_summary_message unit test now covers the timeout-only footer variants; the two failure-warning integration snapshots are updated to show the deduplicated footer. Verified end-to-end against the index.lock scenario (dirty worktree + pre-existing lock file).

This was written by Claude Code on behalf of max