Task IDs are used raw across filesystem and regex deletion paths

[armchairo]

Task identifiers are used as raw values for filesystem paths and regex operations in multiple paths, enabling malformed or special-char IDs to bypass expected separation.

Apply one canonical task ID validator at creation and all lifecycle call sites, and replace regex-based registry deletion/comparison with literal parsed-record comparisons.

Please add tests for separators and regex metacharacters across brief creation, promote, merge-local, and teardown paths (local and remote).

[kunchenguid]

Speaking as Kun's firstmate: this is not waiting on you and it is not a captain-decision hold — it is labeled ready-for-pr and open for a contributor.

Verified against current main 3d2a08b2097dd24f9ce03fdafe6501e39b79dbd0.

Direct observation (source, not claim), and it is worse than "malformed ids only":

• bin/fm-teardown.sh:2586 deletes the secondmate registry entry with grep -vE "^- $id( |$)" "$SECONDMATE_REG" > "$tmp" — the task id is interpolated raw into an extended regex.
• The canonical validator fm_task_id_path_safe() (bin/fm-pr-lib.sh:93-99) accepts [A-Za-z0-9._-] (rejecting only empty, leading-dot, and anything outside that set). . is inside the accepted set and is an ERE metacharacter, so a perfectly valid id such as a.b produces the pattern ^- a.b( |$) and also matches (and therefore deletes) a registry line for a sibling id like axb. The exposure does not need a malformed id at all — it exists for ids the validator already blesses.
• That validator is called in only a handful of places on main: bin/fm-pr-lib.sh:103, bin/fm-teardown.sh:202 (entry) and :1000, bin/fm-procevent-lib.sh:47, bin/fm-procevent-when.sh:103. fm_task_id_creation_valid() exists at bin/fm-pr-lib.sh:106, so a creation-side validator is present, but the "one canonical validator at all lifecycle call sites" your report asks for is not what main does today.

Two separable pieces of work, and I would take them in this order: (1) replace the regex-based registry deletion with literal parsed-record comparison — the registry already has parsed-record helpers (secondmate_registry_parse_line, secondmate_registry_validate_bindings) that this deletion path bypasses; (2) converge the id validators and cover the separator/metacharacter cases across brief creation, promote, merge-local, and teardown (local and remote), as you asked.

VISION verdict (per rule, fetched fresh from main):

1. One captain, one interface — aligns. Deleting the wrong registry row is a silent loss that surfaces later as a confusing outcome; nothing should fall through the cracks.
2. Authority is explicit and never inferred — aligns. A regex match infers which record the id refers to; a literal parsed comparison states it.
3. Scripts own the mechanics, agents own the judgment — aligns. This is the rule most directly at stake: "a rigid script must never adjudicate meaning", and a raw-id ERE is a script adjudicating which record an id means.
4. A restart is a non-event — aligns. The registry is a durable record; corrupting it is exactly the durability promise failing.
5. Delegation with a spine — aligns. Task records are how obligations are closed by records rather than recollection.
6. The fleet outlives any vendor — cannot tell. No vendor coupling either way; the rule does not speak to this change.
7. Scope — aligns. Task lifecycle records are the command layer's own material.

Contract-class: restore. The specified default path already promises that a lifecycle operation on id X touches only X's own record; the raw-regex deletion breaks that existing promise rather than introducing a new behavior. Two fences for whoever picks this up, so it stays restore: literal comparison must not change the registry's on-disk format, and tightening the accepted id charset would be a new default (it can reject ids that are valid today) — that half needs Kun's word, so prefer fixing the comparison over narrowing the validator.

No implementation PR from me. Nothing open covers it: #2591 refuses task-id reuse and #3294 accepts composite Orca worktree ids for teardown; neither touches the raw-regex deletion.