fix(fugu): accept a bare-int access index in the workflow parser (#225)

[minion1227]

Fixes #225

Problem

_normalize_access in src/trinity/fugu/workflow.py validates one access_list entry of a Conductor workflow proposal. It accepts a scalar string digit ("0" -> [0]), None/"" (-> []), and lists of indices — but a bare scalar int (0) falls through every branch to return None, which rejects the entire workflow.

Two semantically identical proposals therefore disagree purely on notation:

parse_workflow('model_id=[0,1]\nsubtasks=["solve","answer"]\naccess_list=[[], 0]',   3)  # (None, False)  <- dropped
parse_workflow('model_id=[0,1]\nsubtasks=["solve","answer"]\naccess_list=[[], "0"]', 3)  # parses fine

A bare integer is the most natural thing a model emits for "read step N", and the parser's stated design goal is to avoid false negatives. Rejecting it depresses parse-rate on otherwise-valid workflows — and a rejected workflow means parsed_ok=False, training_reward=0.0, is_correct=0.

Fix

Add a bare-int branch returning [acc] when 0 <= acc < step_index, matching the already-accepted "0" / [0] forms. bool is rejected first, since it subclasses int and is never a step index.

Tests

Adds tests/test_fugu_workflow_bare_int_access.py (17 cases, offline — no GPU/network):

• the three equivalent forms (0, "0", [0]) all parse and produce an identical workflow
• a bare int normalizes exactly like its string and list spellings
• guards that must still reject: True/False (bool-before-int ordering), negative indices, forward references (>= step_index), self-reference at step 0, and a bare-int forward reference still rejecting the whole workflow
• pre-existing forms (None, "all", "", "query", [0,1], junk) unchanged

Full root suite: 263 passed (existing test_fugu_workflow.py green); ruff clean.

[minion1227]

Overlap with #226 — that PR came first

To be upfront: @galuis116's #226 fixes this same issue and was opened 2026-07-17, six days before this one. The core change is the same in both (a bare-int branch in _normalize_access, with bool rejected first because it subclasses int), and it was arrived at independently. Priority is theirs; the merge call is the maintainer's, and I'm happy for #226 to be the one that lands.

Flagging the differences only so nothing useful gets lost whichever way that goes:

• Docstring. This PR also updates _normalize_access's docstring, which enumerates the valid forms — it currently reads "a list of integer indices" and is left stale by a fix that adds a scalar form. fix(fugu): accept a bare-int access index in workflow parsing #226 changes only the body.
• Self-reference at step 0. _normalize_access(0, 0) is None — the boundary where the 0 <= acc < step_index guard has an empty valid range. Not covered by fix(fugu): accept a bare-int access index in workflow parsing #226.
• Forward reference through the parser. fix(fugu): accept a bare-int access index in workflow parsing #226 tests forward/negative rejection at the unit level (_normalize_access(3, 3), _normalize_access(-1, 3)); this PR additionally asserts end-to-end that a bare-int forward reference still makes parse_workflow return parsed_ok=False — i.e. that widening the accepted forms didn't accidentally let an invalid DAG through the whole parse path.
• Regression guard on the untouched branches. None, "all", "", "query", [0, 1], and junk are pinned so a later edit to the surrounding branches can't silently change them.
• Equivalence is asserted on the whole workflow, not just steps[1].access — the three spellings must produce identical parsed objects.

If #226 lands first I'll close this and re-send the docstring fix plus the four extra cases as a small follow-up on top of it.

CI: register_submission failure is not from this PR

The red check is repo-wide infrastructure, not this diff. actions/checkout now refuses to check out fork code under pull_request_target (pwn-request guard), so the job fails at checkout on every fork PR — currently #226, #232, #233, #239 and this one. Because pull_request_target runs the workflow definition from base main, it cannot be fixed from a PR branch. #233 already proposes the fix (dropping the unused checkout step from that job).

All substantive checks pass here: test-router, test-validator, web, and check_submission_body.