fix(fugu): accept named workflow lists in any order

[tryeverything24]

fix(fugu): accept named workflow lists in any order

Summary

The Conductor proposes a workflow as three parallel lists, each keyed by name
(model_id / subtasks / access_list). The parse-gate in
parse_workflow (src/trinity/fugu/workflow.py) already disambiguates the
three lists by name, but the candidate-pairing loop additionally required
them to appear in that exact textual order:

if s_pos < m_pos:      # subtasks must come after model_id
    continue
if a_pos < s_pos:      # access_list must come after subtasks
    continue

A perfectly well-formed proposal that emits the three correctly-named lists in
a non-canonical order (e.g. access_list before subtasks) therefore fell
through to return None, False. That surfaces as parsed_ok=False, so the
reward layer scores the workflow 0 even though the proposal was valid —
directly corrupting the GRPO training reward signal. The ordering constraint
was never semantically needed, since the lists are already keyed by name.

Fix

Keep the ordered search as a first pass (unchanged), then add an
order-independent second pass that runs only when the first pass finds
nothing and inspects only the triples the first pass skipped (non-canonical
order):

• First pass — canonical textual order (model_id, then subtasks, then
  access_list). Preserves every existing pairing, and still lets a
  scratch/reasoning list that precedes the real block be skipped over.
• Second pass — tries the remaining (non-canonical-order) name-keyed
  triples, guarded by if m_pos <= s_pos <= a_pos: continue so it never
  re-examines a triple the ordered pass already handled.

Every gate in _validate_workflow_lists still applies in both passes, so
malformed proposals (missing/extra list, length mismatch, non-int or
out-of-range model_id, forward reference, empty subtask, over-length
workflow) still fail exactly as before.

Provably non-regressive: the ordered pass runs first and returns on the
first success, so control only reaches the second pass when no canonical
ordering validated. The second pass explicitly skips canonical-order triples.
It can therefore only add acceptance for previously-rejected valid inputs —
it can never change or lose an existing pairing.

Tests

Added test_parse_accepts_named_lists_in_noncanonical_order (mirrors the
existing style in tests/test_fugu_workflow.py): a valid proposal with the
three named lists in a non-canonical order (access_list before subtasks)
now parses successfully and yields the correct steps. Red before the fix,
green after.

Local verification (venv, PYTHONPATH=src):

• ruff check — clean
• mypy src/trinity/fugu/workflow.py — clean
• pytest tests/test_fugu_workflow.py -q — 9 passed (8 pre-existing + 1 new)

The full-suite failures in tests/test_torch_optim_sft.py are pre-existing on
origin/main and unrelated to this change (a different module that does not
import trinity.fugu.workflow); this change introduces no new failures.