feat(dashboard): show lane parallelization in wave chips + task title in lane view (#484, #485)

[HenryLach]

Two dashboard enhancements bundled in one PR. Both are display-only — cannot affect orchestrator correctness even if rendered imperfectly. Visual validation will happen during the next live batch run.

#484 — Lane parallelization in wave indicator chips

Before:

Waves   W1 [TP-165, TP-166, TP-168, TP-167]   W2 [TP-169, TP-170]   W3 [TP-171]

W1 looks like 4 independent tasks. In reality TP-165→TP-166 are serialized on lane 1 while TP-168 and TP-167 run in parallel on lanes 2 and 3.

After:

Waves   W1 [TP-165 → TP-166 | TP-168 | TP-167]   W2 [TP-169 | TP-170]   W3 [TP-171]

Same-lane tasks join with → (serial). Different-lane tasks join with | (parallel). At a glance:

• Count of | separators = number of parallel lanes used in the wave
• → arrows = serialized tasks on a single lane

Hover tooltip on each chip exposes the expanded lane breakdown:

W1
  L1: TP-165 → TP-166
  L2: TP-168
  L3: TP-167

Implementation

• New helper formatWaveLaneBreakdown(taskIds, lanes, waveNumber) in dashboard/public/app.js
• Within each lane, tasks render in execution order (sorted by their position in lane.taskIds), not by their appearance order in the wave's task list
• Future waves with no lane assignment data (lanes provisioned per-wave when wave starts) fall back to the previous flat comma-separated display — zero regression for unprovisioned waves
• No server changes: lanes data is already exposed via /api/state

#485 — Task title under task ID in lane view

Before:

●  👁 TP-165                    ● running    11m 11s    ━━━━━━━━━  0% 0/18

After:

●  👁 TP-165                    ● running    11m 11s    ━━━━━━━━━  0% 0/18
      Segment Boundary .DONE Guard and Expansion Consumption

Operator no longer needs to remember what each TP-XXX means.

Implementation

• New helper parseTaskTitle(taskFolder) in dashboard/server.cjs reads the title from PROMPT.md's # Task: <ID> - <title> first-line heading. Regex: /^# Task:\s*\S+\s*[-—–]\s*(.+?)\s*$/m (handles dash, em-dash, en-dash separators).
• Per-folder cache for the server lifetime: PROMPT.md is immutable above the --- divider so the title never changes mid-batch.
• /api/state task records now carry a taskTitle field alongside the existing statusData.
• Frontend wraps the task-id cell in a flex column with the ID on top and the title as a smaller muted subtitle underneath. Falls back gracefully (no subtitle div) when taskTitle is null.
• New CSS: .task-id is now flex-column; .task-id-line preserves the monospace ID look; .task-title-subtitle is the smaller muted line with ellipsis truncation for long titles.

Validation

• ✅ Logic unit-tested in isolation for formatWaveLaneBreakdown:
  • Issue example: TP-165 → TP-166 | TP-168 | TP-167 ✓
  • Scrambled appearance order: still renders lane execution order correctly ✓
  • Future wave with no lane data: falls back to flat display ✓
  • Empty input: returns empty strings ✓
• ✅ No backend behavior change for parseTaskTitle (purely additive read of PROMPT.md, cached, fail-safe to null)
• 🔵 Visual validation deferred to next live batch run

Operator note

Per the supervisor primer rule, after this PR merges and a new dashboard binary lands, restart the dashboard server to pick up the new server-side parseTaskTitle logic. Frontend-only changes refresh on browser reload, but the new API field requires a server restart.

Closes

• Closes Dashboard: show lane parallelization in wave indicator chips #484
• Closes Dashboard: show task title under task ID in lane view #485