e2e: two task-status assertions read through hub.request instead of the UI

[lsm]

CLAUDE.md bars hub.request in e2e test bodies — it is permitted for setup and teardown only, because tests are supposed to act through the visible browser UI. Two places break that:

• packages/e2e/tests/features/post-approval-no-route.e2e.ts:99 — reads the task and feeds expect(status).toBe('approved') directly. The assertion never looks at the rendered page, so the test would pass even if the UI showed nothing.
• packages/e2e/tests/features/space-happy-path-pipeline.e2e.ts:191 — reads status and then drives two spaceTask.update mutations mid-test before asserting on rendered text.

Both predate #4529, which only swapped the read's transport onto task.get and deliberately did not change assertion behavior. Flagged during review of that PR.

The fix is to assert through the task UI — the status chip in the task pane — and, for the pipeline spec, to decide whether the mid-test mutations are legitimate setup for the next assertion or should be driven through the UI as well.

Not urgent, and not a blocker for the spaceTask.* retirement: the second one will need revisiting anyway when spaceTask.update is wired onto task.update.