feat: create a new repo (or fork) plus environment from within Roomote

[mrubens]

What

Makes brand-new GitHub repositories a first-class setup target instead of a dead end. Users can now click "Create a new repository" in Roomote, create the repo (or fork one by URL) on github.com, and have Roomote pick it up automatically, bootstrap it if it's empty, and set up a basic environment — no repo-creation API permissions required.

Why

Today repos only enter Roomote via GitHub App installation sync, and empty repos hit a hard wall: onboarding blocks with "Push an initial commit before continuing." Going from "I want a new project" to a working environment required manual round trips through GitHub and git. Creating repos via API would have required administration:write on the App manifest (with a manual permission-update step for every existing self-hosted App, and no coverage for personal accounts) — so instead the flow sends the user to github.com/new and automates everything after that click.

How

Backend

• New handleInstallationRepositoriesChange webhook handler registered for installation_repositories.added/removed (selected-repos installs) and repository.created/deleted/renamed (all-repos installs), performing a full syncGitHubInstallation resync. No manifest change needed: installation_repositories is auto-delivered to GitHub Apps and Repository is already in GITHUB_APP_DEFAULT_EVENTS.
• Worker: syncRepositoryGitState now detects a branchless remote in the branch-resolution failure path, points the unborn HEAD at the stored default branch, and skips the remote-ref sync steps. SHA pins against empty remotes throw a clear error; local commits in a reused workspace are preserved.
• Environment-setup skill: new "Bootstrap an empty repository" step — push exactly one initial commit (README + .gitignore) to the default branch, never force-push, then define the smallest valid environment. Explicitly no app scaffolding; building the project is the user's first task.
• buildCreateEnvironmentDefinitionPrompt gains optional emptyRepositoryFullNames (byte-identical output when absent; the prompt restates bootstrap rules inline as an N-1 fallback for worker images whose packaged skill predates the section). The onboarding assertHasCommittedRepositorySelection throw is removed — empty selections proceed.

Web UI

• New CreateGitHubRepoDialog: "New repository" tab (opens github.com/new?owner=<login> with the installation owner prefilled) and "Fork existing" tab (paste a URL or owner/repo → GitHub's fork page). Polls the repository list while open, syncs on return to the tab, offers manual refresh and the inline Update GitHub flow, and surfaces newly appeared repos with a "Use this repository" action.
• Wired into onboarding repo selection (empty-repo wall becomes an informational note with Continue enabled), Settings > Environments > New (including a ?create-repo=1 deep link), and the workspace picker (admin-only "New GitHub repository" item).
• Docs: "Start from a brand-new repository" section in environments.mdx; webhook-event note in the GitHub provider guide (apps predating the Repository default event should confirm it's enabled — there's no API to update app event subscriptions).

Zero DB schema changes.

Testing

• New/extended unit tests across apps/api (webhook handler, known-installation gating), apps/worker (empty-remote sync paths), packages/cloud-agents (skill guardrails), packages/types/apps/web (prompt builder variants, command plumbing, dialog, onboarding step, environments page, workspace picker).
• pnpm lint, pnpm check-types, and pnpm knip pass.
• Still owed before merge (needs a live deployment + GitHub App): confirm installation_repositories.added deliveries arrive for a manifest-created App, and one end-to-end run of create-empty-repo → auto-detect → bootstrap → verified environment.

[roomote-roomote]

No new code issues found. See task

_{Reviewed bc7a9f1}