fix: allow empty project-set creation while sync is offline

[mvanhorn]

Fresh Quarto Hub users currently cannot finish setup when the configured sync server is unavailable. The active useCollectionSets flow calls createCollection, which waits up to ten seconds for a peer and throws before importing the empty root document, so the hook enters error and the setup screen returns. Because the document is empty and the Repo already has IndexedDB storage plus a reconnecting WebSocket adapter, the personal root can be created and used locally before a peer is available. Existing-set linking must still require either a cached document or a reachable server.

Summary

Add an explicit creation policy in projectSetService.ts: ordinary shared collections remain server-gated, while the fresh personal-root wrapper imports the empty document immediately, flushes it to IndexedDB, and observes server readiness in the background so a later reconnect can sync it. Update useCollectionSets.ts to use that offline-capable wrapper only for createProjectSet; migration and user-created shared collections continue through the server-gated path to avoid changing their durability guarantees. Preserve the configured sync-server URL in both stored pointers so reloads reopen the cached root and resume background synchronization against the intended server.

Verification

• Happy path: with a reachable server, creating a fresh personal root immediately persists both pointers, reaches the projects home, and the background peer connection synchronizes the empty document.
• Edge cases: with no peer, creation still reaches connected; after a reload the cached empty root opens from IndexedDB and retains its configured server; migrations and ordinary shared-collection creation remain server-gated.
• Error paths: IndexedDB import or flush failures still surface setup error state, and linking an uncached existing project set while offline still reports that the collection must first be synced online.

Closes #405

AI was used for assistance.

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[cscheid]

Thanks for the PR! But, to be frank here: this part of the code base is moving pretty fast, and, well, we don't know you! I'm not sufficiently confident that I understand what's happening here to merge without further discussion. Can you yourself (not your LLM agent) give me more context?

[mvanhorn]

Fair ask. Short version of what I hit and why the change looks like this.

I was setting up a fresh Hub with no sync server reachable. Setup dies before it ever reaches the empty root document, because createCollection blocks waiting for a peer for ten seconds and then throws. The document it is waiting to sync is empty, and the Repo already has IndexedDB storage plus a reconnecting websocket adapter, so nothing actually needs a peer at that moment.

So I kept the change narrow: only the fresh personal-root path imports the empty doc locally and lets the peer connection catch up in the background. Shared collections and the migration path still go through the server-gated call, since those can carry real content and I did not want to weaken their durability. Linking an existing set still refuses when there is no cached doc and no server, because that one genuinely needs data from somewhere.

Happy to split it smaller or drop the e2e spec if that makes review easier. And if you would rather not take this from someone you do not know while this area is moving fast, no hard feelings, I would rather you close it than carry a review you are not comfortable with.

[cscheid]

(Hey, I'm sorry, but your response really makes me think I'm still talking to Claude. Please use your own voice, it really makes it easier for us if we're talking to, you know, people)

If you're setting up quarto hub for yourself, you could always point it to sync.automerge.org (if you're ok with your projects being synced locally), or to a port you open with q2 hub. Making everything work perfectly in local-first mode is something we want to eventually do, but not something we can reasonably promise to maintain during this high-volatility part of the project. So I don't want to accrue maintenance debt in this area.