`mship view spec --task <slug>`: filename-match fallback before newest-by-mtime

[atomikpanda]

Observed

In a fresh task with no .mothership/tasks/<slug>/SPEC.md blessed path, mship view spec --task <slug> falls back to "newest-by-mtime in docs/superpowers/specs/" — which surfaces the wrong file when a more-recently-edited spec is for a different task.

Concrete case from a recent session: a task named task-dependency-graph, with docs/superpowers/specs/2026-05-14-task-dependency-graph-design.md present in the repo. mship view spec --task task-dependency-graph returned 2026-04-28-hub-worktree-layout-design.md (referencing #87) instead, because the blessed path didn't exist and the hub-layout spec was newest-by-mtime.

Why this matters

--task <slug> is a strong hint that the user wants the spec FOR that task. The newest-by-mtime fallback ignores that hint. Today the workarounds are:

• Manually create the .mothership/tasks/<slug>/SPEC.md symlink (the blessed path is undocumented).
• Pass the spec filename explicitly (defeats the point of --task).

Suggested direction

In mship.core.view.spec_discovery.find_spec, when task is set, name_or_path is None, and the blessed path is missing, insert a filename-match step BEFORE the newest-by-mtime fallback:

• Glob the search roots for *<slug>*.md (case-insensitive).
• Exactly one match → return it.
• Multiple matches → return the newest, emit a stderr note naming the chosen file.
• Zero matches → current behavior (newest-by-mtime in the spec dir).

Acceptance

• A spec whose filename contains the task slug is found by mship view spec --task <slug> without a blessed-path symlink.
• A task with no matching spec falls back to newest-by-mtime (unchanged).
• Multi-match prints a one-line stderr note about which file was chosen.

Related

• Discovered while working on First-class task dependency graph (blocks / depends-on) — design issue, marinating #104.
• See BLESSED_TASK_SPEC_DIR and find_spec in src/mship/core/view/spec_discovery.py.