feat: route create project to edit session

[AdityaHegde]

1. Updates the create project flow to route to edit session. Routes directly to welcome page after project creation.
2. If project has no rill.yaml then automatically route to welcome page. This mimics the behaviour on rill-dev.
3. Updates the routes for project welcome to be under /-/edit.
4. Also adds a redirect to edit page for unpublished projects.

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

[ericokuma]

https://www.loom.com/share/5540a8a60ae44249b27a3ef1113c8d62

[ericokuma]

LGTM!

[ericpgreen2]

Product / UX

Project URLs without an explicit branch bounce viewers into the editor. When a project has only an editable dev deployment (no active prod), a URL like /{org}/{proj}/explore/dash1 is redirected into the editor. A read-only viewer who follows a share link lands on the editor instead of the dashboard they were sent to. URLs that include the branch — /{org}/{proj}/@dev/explore/dash1 — already do the right thing. Extend that behavior to URLs without a branch: redirect to the same path on the editable branch (the preview surface), so viewers see the dashboard. Users with edit permission can click the Edit button to switch into editing.

Engineering Implementation

1. Add unit test coverage for the redirect logic. maybeRedirectToEditableDeployment is a pure async function — vitest tests covering the active-prod, no-prod, and branch-match cases would lock in the behavior cheaply. The three layout loaders that contain redirect logic can also be tested with mocked load context. The "Covered by tests" checkbox is unchecked.

2. Drop the (misc) addition to the parity script. (misc) is a catch-all containing welcome, deploy, and root-level routes — it has nothing to do with the editor surface. Adding it forces 12 deploy-related allowlist entries (deploy is fundamentally local-only and won't ever exist on cloud), and it nudges welcome toward 1:1 parity with local — which isn't what we want, since the cloud and local welcome flows legitimately differ in telemetry, starter set, and next-step destinations. The parity script earns its keep by unifying the editor surface; welcome and deploy live outside that scope.

3. Welcome routing — non-blocking, but worth a ticket. Two issues with how welcome is wired up today:

   • /-/edit/welcome nests onboarding inside the editing surface. These are different user states, and combining them in the URL hierarchy is conceptually awkward.
   • Welcome state is tracked in two places: an in-memory projectWelcomeStatus flag, and whether rill.yaml exists. When the two disagree, direct navigation to /-/edit/welcome cycles through /-/edit and back before settling.

   Both feel right to revisit when the welcome flow is reconsidered as part of AI-first.

---

Developed in collaboration with Claude Code

[AdityaHegde]

Thanks @ericpgreen2 .
Updated the redirect logic to only redirect to the root /<org>/<project>/@<branch>. User has to click edit to actually edit the deploymnent.

1. Added tests to all of those.
2. Dropped the (misc) but added welcome to admin allow list. Will do a follow up to match rill-dev, it needs additional testing which I want to avoid in this PR.
3. a. The /-/edit route is meant to be somewhat of a mirror of rill-dev. So it makes sense for welcome that does a step-by-step initial edit to be here. Otherwise we would need to replicate layout code for edit for welcome as well. AI-first will probably still be under /-/edit since we are doing an edit through developer agent.
   b. The place that tracks rill.yaml existence sets projectWelcomeStatus so /-/edit/welcome will not redirect back. rill.yaml tracking is for users who closed the tab before starting with welcome step. projectWelcomeStatus is for subsequent steps after a rill.yaml is created like creating a model and dashboard but still in welcome status. This mimics the rill-dev behaviour.