Improve UX when Taskplane is not configured in current workspace

[mwickens]

Summary

When using pi in a directory where Taskplane is not configured, startup is blocked with:

Error: ❌ Orchestrator startup blocked [WORKSPACE_SETUP_REQUIRED]

along with a long red error explanation.

This feels too heavy for users who do not want Taskplane enabled in every location.

Steps to reproduce

1. Open pi in a location/workspace where Taskplane has not been set up.
2. Start the orchestrator flow (or run a command that triggers Taskplane startup).
3. Observe startup is blocked and a long red error message is shown.

Actual behavior

• Hard-blocking startup in non-configured locations.
• Verbose red error output that reads like a failure state.

Expected behavior

• More graceful handling when Taskplane is not configured in the current workspace.
• Prefer a non-blocking path, such as:
  • auto-fallback to normal (non-Taskplane) behavior, or
  • lightweight warning + optional "Set up Taskplane" action.
• Keep messaging concise and calm (avoid alarm-style red wall of text unless truly fatal).

Why this matters

Many users only want Taskplane in specific projects. The current behavior makes that common workflow feel broken instead of optional.

Possible implementation ideas

• Add a soft-fail mode for WORKSPACE_SETUP_REQUIRED.
• Gate strict blocking behind an explicit "Taskplane required" setting.
• Provide a one-line warning with a hint command (expandable details only on request).

[HenryLach]

Fixed in PR #534 (merged as 00a6231) — TP-183.

What shipped:

• session_start handler in extension.ts now soft-fails the WORKSPACE_SETUP_REQUIRED case specifically: no error notification, status line shows the quiet 🔀 Orchestrator · disabled (no taskplane config in workspace) indicator, orchestrator commands stay gracefully disabled (and still explain why if invoked, via the existing requireExecCtx guard).
• All other WorkspaceConfigErrorCode values (WORKSPACE_FILE_PARSE_ERROR, WORKSPACE_SCHEMA_INVALID, WORKSPACE_REPO_PATH_NOT_FOUND, etc.) still surface loudly with the existing red error notification — those remain real misconfigurations.
• Test coverage: 7 source-pattern assertions in orchestrator-startup-uxv2.test.ts covering the soft-fail branch, the loud-fail regression guard, success baseline, and a global-scope guard (added during sage code review) ensuring notify(error) appears exactly once and only inside the loud arm.

Code review: sage advisory review post-merge (TP-184's bridge-tools fix was not yet active when TP-183's worker ran, so automated plan/code reviews didn't fire on that batch). Sage flagged no blocking issues; one optional improvement (global-scope assertion) was applied as a follow-up commit before integration.

Deferred follow-ups (TP-186 candidates): extract startup display logic into a pure helper for true behavioral testing (vs. current source-pattern testing).

Thanks @mwickens for the report.