Targets dev.

Who is submitting this PR? (required)

What problem are you trying to solve?

skills/subagent-driven-development/scripts/task-brief extracts one task's
text from a plan by string-concatenating the requested task number directly
into an awk regex:

intask = ($0 ~ ("^#+[ \t]+Task[ \t]+" n "([^0-9]|$)"))

This has two silent failure modes (issue #2405):

1. Prefix match. In a plan with dotted sub-task numbers (Task 1.1,
   Task 1.2, ...), running task-brief PLAN 1 returns every Task 1.x
   concatenated together, because . counts as the "non-digit" terminator
   the regex uses to stop a plain integer match.
2. Unescaped metacharacters. The task number is never validated or
   escaped before being spliced into the regex: task-brief PLAN 2.1 also
   returns Task 201 (the . in 2.1 matches as regex "any character"),
   a task number like 2|3 returns both tasks, and a task number like 2(
   crashes awk with a raw syntax error instead of a clean usage message.

Every failure mode above exits 0 (or an unhandled awk crash) and hands the
implementer a brief that silently contains the wrong text, or more than one
task's text concatenated together — the brief is the implementer's single
source of requirements, so this is a correctness bug in the one thing the
script exists to get right.

What does this PR change?

Validates the task number up front against the only shape a real Task N
heading can have (digits, optionally dot-separated, e.g. 3 or 2.1),
rejecting anything else with a clear error and exit 4. The awk program
itself no longer interpolates the task number into a regex at all — it
extracts each candidate heading's full number and compares it to the
requested number as an exact string, so a shorter number can never
prefix-match a longer sibling.

Is this change appropriate for the core library?

Yes — task-brief is a core SDD script shipped with the plugin, used by
every subagent-driven-development run. This is a correctness fix to
existing shipped behavior, not a new feature, integration, or
project-specific addition.

What alternatives did you consider?

• Keep interpolating into the regex but escape metacharacters first.
  Would fix the injection/crash case but not the prefix-match case (a
  plain digit search still can't distinguish "1" from "1.1" without also
  changing the terminator logic). Doing the comparison as a plain string
  equality after extracting the heading's own number fixes both problems
  in one change and is simpler to reason about than an escaped,
  hand-built regex.
• Just tighten the terminator regex (e.g. require [^0-9.] instead of
  [^0-9]). This still leaves n unescaped and vulnerable to the
  metacharacter/injection case, and doesn't handle 2.1 vs 201 cleanly
  since the terminator approach never actually captures the heading's own
  number for comparison.

Does this PR contain multiple unrelated changes?

No — one script, one behavior (exact task-number matching), with the test
coverage for that behavior in the same commit.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: fix(sdd): stop task-brief swallowing letter-suffixed sub-tasks (#2175) #2176 (letter-suffixed sub-task boundary, a different root
  cause — still admits . and doesn't touch this prefix/injection bug),
  task-brief: track fence character and length so fenced examples cannot end a task early #2304 (fence tracking — a different bug in the same script), fix(sdd): stop task-brief leaking trailing plan sections #2359
  (trailing-section leakage — a different bug in the same script), fix(sdd): support alphanumeric task IDs #2466
  (alphanumeric task IDs — a different, additive feature). None of these
  change the number-matching logic this PR fixes; "none found" for this
  specific bug.

Environment tested

Evaluation

• What was the initial prompt you (or your human partner) used to start
  the session that led to this change? A recurring nightly task to survey
  open issues in this repo and fix one small, clearly-specified,
  verifiable bug.
• How many eval sessions did you run AFTER making the change? Ran the
  full tests/claude-code/test-sdd-workspace.sh suite (28 assertions,
  all passing) plus the adjacent test-executing-plans-scripts.sh and
  test-worktree-path-policy.sh suites to check for regressions.
• How did outcomes change compared to before the change? Before: the
  three new assertions reproducing issue task-brief: task number is an unanchored, unescaped regex prefix, so the wrong task is returned with exit 0 #2405's exact repro all failed
  (confirmed RED against the unmodified script — prefix match returned
  concatenated tasks, 2.1 returned 201 too, and 2( crashed awk).
  After: all three pass, and no previously-passing assertion in the
  suite regressed.

Rigor

• If this is a skills change: I used superpowers:writing-skills and
  completed adversarial pressure testing (paste results below)
• This change was tested adversarially, not just on the happy path
  (the new tests cover the prefix-collision case, the "longer sibling
  number" case, and a deliberately malicious/malformed task number)
• I did not modify carefully-tuned content (Red Flags table,
  rationalizations, "human partner" language) without extensive evals
  showing the change is an improvement

Human review

• A human has reviewed the COMPLETE proposed diff before submission

Per the note above: this PR has not yet had a human review pass. The
change is two files (one 23-line script diff, one 53-line test addition)
and I believe it is ready for maintainer review, but I'm leaving this box
unchecked rather than checking it falsely.