e2e: make the specs independent of who owns the seeded records (option 2 from #665)

[os-zhuang]

Follow-up to #665, filed by the PR that implemented option 3 there
(#668). Unassigned on purpose — this is the deliberate,
larger change #665 deferred, not a leftover of it.

Where things stand after #665

#665's PR added a precondition guard to e2e/global-setup.ts: when the seeded
rows are not readable by the account the suite signs up, the run now aborts with
the actual cause and a remedy instead of eleven specs failing on "no seeded
accounts returned". That converts a confusing failure into an instruction. It
does not remove the dependency it names — the suite still needs somebody else's
records to be visible to it, and that is an environmental property, not
something the suite establishes.

Measured while implementing it, on 17.0.0-rc.2:

• objectstack start (CI's webServer) seeds no dev admin, so the e2e account
  is the org's first user — sys_user holds exactly one row — and
  demo_bootstrap claims every seeded record for it. That, and only that,
  is why CI is green.
• objectstack dev (pnpm dev) seeds admin@objectos.ai. The first user is
  then that admin, and at the next wall-clock ten-minute boundary the sweep
  claims the seeds away from the e2e account. Measured: a dev server booted at
  :49 had all 9 seeded accounts carrying the dev admin's owner_id by :50.

So local runs against pnpm dev are unusable past the first sweep, and CI's
green rests on an accident of which user happens to be created first.

What this issue asks for (option 2 in #665)

Make the specs independent of who owns the seeded records. Sketch, not a
prescription — the shape is the decision this issue exists to make:

• give the e2e account an explicit grant after sign-up (a permission set, a
  sharing grant, or a position the shipped rules already route to), or
• have the seed-dependent specs create the records they assert on, so the suite
  reads what it owns and the seeds are only a backdrop.

Both change what the suite proves, which is why #665 did not do it in passing.
The second is the more faithful "a normal user drives the app", and would also
let the specs run against a long-lived dev server, a shared environment, or a
box where demo:staff has run — none of which work today.

Acceptance criteria

• pnpm test:e2e passes against a dev server that has been up for more than ten
  minutes, and after pnpm demo:staff, with no pnpm demo:reset in between.
• CI stays green, and stops depending on the e2e account happening to be the
  first user in the org.
• Whatever the suite proves about access control after the change is stated in
  e2e/fixtures.ts — an authenticated read that succeeds because the caller was
  handed viewAllRecords proves something different from one that succeeds
  because it owns the row, and the file should say which.
• The #665 guard in e2e/seed-precondition.ts is re-examined: if the suite no
  longer depends on seed ownership, the "claimed" branch becomes unreachable and
  should go rather than linger as a comment about a solved problem.