docs: order the issue #18 work so nothing deletes the shared table

The plan's one irreversible risk is the worst-case test itself. It
deliberately lets the script fall through to the shared table, and the
account in .env is a superuser, so running it before the sandbox role
exists would delete every expired row in there. All eleven rows on that
table predate any cutoff the tests use.

That forces the order: factory, then the retention tests move onto an
owner role, and only then does the case get written. Review caught that
the original order also made the --table integration cases impossible
to fail first, since the tool would already be implemented by the time
they were written. Same fix resolves both.

The worst-case case has no red-first path at all. Turning it red means
running it as the superuser, which is the thing being prevented, so its
evidence is the probe in the finding instead, and the plan says so
rather than calling it verified.

One acceptance criterion in the design turned out to be unrunnable: the
hint line only prints on the Postgres branch, so no unit test that
never connects can assert it. Corrected in place.

research-wiki/graph/edges.json

@@ -405,6 +405,13 @@
       "relation": "refines",
       "evidence": "复测确认 M3 can_disable 仍成立,并补记非流式不可观测、仅 reasoning_effort 有效两条限制",
       "added": "2026-08-26T04:49:18.648857+00:00"
+    },
+    {
+      "source": "plan:2026-08-26-issue18-pg-test-isolation",
+      "target": "design:2026-08-26-issue18-pg-test-isolation",
+      "relation": "implements",
+      "evidence": "9 个任务逐条实现设计 §4-§11",
+      "added": "2026-08-26T11:28:33.469681+00:00"
     }
   ]
 }