[Regression][0.20.0] Reloading a generated artifact loses project files and preview

[open-design-crew]

Summary

On the open-design-v0.20.0 release tag, reloading a project after a real daemon run has generated and opened an HTML artifact can lose the active project file state. The page comes back as shared/read-only with an empty Design Files view and no active preview.

Current behavior

The generated artifact opens and renders successfully before reload. After page.reload() on the same project detail route:

• the UI reports the project as shared/read-only;
• Design Files is empty;
• the active artifact preview iframe is gone;
• the existing reload-restoration assertion fails.

The first-paint stability observation passes before reload, so this is distinct from the initial artifact white-screen/remount problem.

Expected behavior

Reloading the project detail route should preserve the local project's authority, file list, selected artifact tab, and visible preview.

Steps to reproduce

1. Check out open-design-v0.20.0 (fa3cb4cdf3d1703e984a5655bd9654f8d44c493b).
2. Run the real-daemon Playwright artifact flow in e2e/ui/real-daemon-run.test.ts.
3. Create a project and deliver the deterministic HTML artifact through the fake agent and real daemon.
4. Confirm the generated heading is visible and the same preview iframe remains connected during the settle window.
5. Reload the current project detail page.
6. Observe shared/read-only state, empty Design Files, and no active preview.

Notes

• Release comparison baseline: open-design-v0.19.2 → open-design-v0.20.0.
• The same real-daemon route passed on main@057b0f4e1, including file/raw checks and reload restoration, so the failure appears specific to the v0.20.0 backport line.
• The failure occurred in the pre-existing post-reload preview restoration assertion, not in the newly added iframe stability assertion.
• This report records the release-tag regression only; no product fix was attempted during the E2E coverage audit.

Why this matters

The user can successfully generate an artifact and still lose access to it on the first reload. That makes the core project-detail delivery path appear destructive and can be mistaken for a blank artifact or missing generation result.

[lefarcen]

Thanks for the crisp regression report — the distinction between "first paint is stable" and "reload drops the project into shared/read-only with an empty Design Files state" is especially helpful.

This looks related to the earlier reload/persistence work in #4607 and the later workspace-authority fix in #6989, but not like a straight duplicate: here the artifact already rendered successfully before reload, so the break seems to be in restoring the project/file authority on the reopened route rather than in the initial daemon delivery path itself.

I've tagged this as a bug and am keeping it tracked as a v0.20.0 regression. The real-daemon repro in e2e/ui/real-daemon-run.test.ts gives this a concrete path to investigate.