feat: step 1 update dev navbar, remove reports, alerts and other Cloud features

[royendo]

Dev deployments should not show reports and alerts and any cloud features in dev cloud preview;

• Reports,
• Alerts,
• Dashboard
  • Bookmarks
  • Creating Alerts
  • Home Bookmark
  • Share
• Settings

Status For Editors will be added in follow up PR
Status for Admins shows

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!

[ericpgreen2]

Centralize "is this a branch preview" as a derived URL-state store, not per-component checks. Three different definitions are now in play:

• ProjectHeader.svelte:80 — !!activeBranch && activeBranch !== primaryBranch (production-aware)
• ProjectTabs.svelte:19 — branchPrefix !== "" (any @branch in URL)
• routes/[organization]/[project]/+layout.ts:22 and status/+layout.svelte:10 — truthy extractBranchFromPath(...) (any @branch in URL)

In the common flow BranchSelector strips @branch for production, so they tend to agree. But a deeplink or bookmark to /<org>/<project>/@<primaryBranch>/-/alerts would hit the redirect (hiding alerts) while ProjectHeader renders production-mode chrome — a real user could land in an inconsistent state.

The cleanest resolution is a single derived store, e.g. isBranchPreview colocated with the rest of the branch utilities:

// web-admin/src/features/branches/branch-state.ts
export const isBranchPreview = derived(
  [page, primaryBranchStore],
  ([$page, $primary]) => {
    const active = extractBranchFromPath($page.url.pathname);
    return !!active && active !== $primary;
  },
);

Components gate with !$isBranchPreview; the layout-level redirect uses the same underlying predicate. This places the concept where it belongs (URL state, not a deployment-capability feature flag), and the inconsistency above collapses into one definition. Worth doing here rather than as a follow-up — every additional call site added before the consolidation is one more thing to migrate.

Bundled scope: EditButton.svelte ownership-check removal. The PR title and description are about hiding cloud features on branch views, but this PR also drops the createAdminServiceGetCurrentUser lookup and the ownerUserId / editable / status filtering on activeBranchDeployment. Now any branch view direct-edits regardless of ownership, deferring to maybeRedirectToEditableDeployment to handle non-owners. This is a meaningful behavior change — either split it into a dedicated PR with its own description, or call it out explicitly here so reviewers know to evaluate it.

---

Follow-up worth filing separately: several adminServer call sites in web-common are using the flag as a proxy for distinct concepts that will diverge once Rill Developer in Cloud and branch previews both land — most notably chat/core/context/picker/data/index.ts:24 (isRillDev = !$adminServer) and DashboardStateDataLoader.ts:265 (empty-data error copy). Tightening adminServer to mean strictly "admin service is available" and migrating these sites to more accurate predicates is out of scope here, but worth queuing.

---

Developed in collaboration with Claude Code