Scaffold breaks the API seam rule when a page needs data with no plan route

Found while running a real end-to-end Create New Project with Copilot project (React + Azure Functions + PostgreSQL). The scaffold agent broke the load-bearing API seam rule in three pages.

What happened

frontend-preview-steps.md:53 states the rule plainly:

Load-bearing seam rule. Pages and hooks NEVER import the mock directly. They import a single api object from services/web/src/api/ (the seam). At scaffold time that api is backed by the mock implementation; at integrate time the integrate agent swaps one file (src/api/index.ts) to point at the live client and deletes the mock impl — no page or hook changes.

At the scaffold gate, three pages imported the mock directly:

NewTask.tsx        import { users }    from '../mocks/data';
TaskDashboard.tsx  import { findUser } from '../mocks/data';
TaskDetail.tsx     import { users }    from '../mocks/data';

validate-frontend-scaffold caught it correctly:

• [apiSeamBypassed] src/pages/NewTask.tsx: Imports "../mocks/data" directly instead of
  the `src/api/` seam, which breaks the one-file swap at integrate time.

Why this isn't simple non-compliance

The pages used the seam correctly for task data — import { api } from '../api' — and reached around it only for user data (rendering an assignee name).

The ApiClient interface is derived from the plan's Route Definitions, and the plan had no /users route. So there was no seam method to get users from. Given the interface it was handed, reaching into the mock was the only way to render an assignee name at all.

What integrate did

Integrate recovered: it edited all three pages, deleted src/mocks/, and pointed src/api/index.ts at liveClient. The final app is correct.

But the rule says the swap should require "no page or hook changes" — integrate had to do extra work to absorb a broken contract. Grading only the final artifact shows a flawless app and hides the violation entirely, which is why this was only visible with a capture taken at the scaffold gate.

Suggested direction

The gap looks like it's between the plan and the seam, not in either alone. Some options:

1. Require the ApiClient interface to cover every entity the pages render, not only entities with plan routes — with reference data served by the mock client behind the seam.
2. Have the plan's Route Definitions include lookup routes for any entity referenced by a Pages table column (here, assignee).
3. Explicitly allow reference-data imports and narrow the seam rule — the weakest option, since it makes the one-file swap conditional.

Whichever way, the instruction should say what to do when a page needs data with no route, because that case is currently undefined and the agent has to improvise.

Repro notes

Prompt: "Build a task tracker with a React frontend, an Azure Functions HTTP backend, and a PostgreSQL database for durable storage. Uploaded attachments are held in Blob Storage." — n=1, so worth confirming this reproduces before acting on it.

Reproduce the scaffold gate with the stated Create New Project with Copilot prompt, then read frontend-preview-steps.md and the validate-frontend-scaffold output. Inspect src/pages/NewTask.tsx, TaskDashboard.tsx, TaskDetail.tsx, and src/api/index.ts to trace the missing reference-data seam. Done means the expected behavior for pages needing data without a plan route is specified and the scaffold-to-integrate flow no longer requires page changes.