Add a first-class actionability layer separate from task status

[justguy]

Problem

Today status, priority, and swimlane are doing too much. When an agent asks "what can I work on next?", the signals it actually needs are scattered or missing:

• Is this task executable now?
• Is it blocked by another task?
• Is it waiting on an operator decision?
• Is it just parked?

status alone (not_started, in_progress, complete, deferred) answers lifecycle, not actionability. As a result lt next can surface rows that are not actually actionable, and briefs don't tell the caller why a task is not ready.

Proposal

Add a derived actionability layer, separate from status.

1. Keep status simple

Lifecycle only: not_started | in_progress | complete | deferred. No new status values.

2. Add a derived actionability block to every brief / next / status view

actionability:    executable | blocked_by_task | decision_gated | parked
blocked_by:       [task ids]
decision_required: bool
decision_reason:   one short sentence

Example — rm-runtime-helper-file-materialization would read as:

• status: not_started
• actionability: decision_gated
• blocked_by: [rm-runtime-substrate]
• decision_reason: choose which helper/checklist behavior becomes load-bearing

3. lt next ranks only executable work by default

• Hide decision_gated rows unless --include-gated.
• Otherwise future agents keep picking up rows that aren't actually actionable.

4. lt brief prints a dedicated header

• Actionability
• Blocked By
• Decision Needed
• Why Not Actionable Now

One-liner

lt needs a derived "can I act on this now?" model, not just lifecycle status.