Formalize the Stargate + Rockets integration

## Why
Stargate (the workflow/flow execution engine, `@stargate/*` packages, sibling repo) is currently wired into Rockets ad-hoc:
- `apps/api/src/stargate-runtime.module.ts` resolves the `.stargate` workspace root and env by walking up the filesystem from `process.cwd()`, and wraps `StargateServerModule` from `@stargate/server/nest`.
- `apps/api/src/modules/stargate/stargate.module.ts` is a thin adapter exposing `StargateCatalogService` / `StargateExecutionService` behind a `STARGATE_RUNTIME` port.
- `apps/api/src/modules/workflows/workflows.resource.ts` imports `StargateModule.register({ workflows: [] })` directly inside a Rockets `defineModuleResource`.
- Config depends on `STARGATE_ENV_ROOT` / `STARGATE_WORKSPACE_ROOT` env vars and local `file:` deps on a sibling `stargate` checkout (see root `package.json` resolutions), which is fragile for anyone cloning `rockets-starter` standalone.

## Scope (to refine)
- Decide the supported integration shape: is Stargate meant to be a required sibling repo for every Rockets project, or should `rockets-starter` vendor/publish the pieces it needs?
- Document/harden the workspace-root resolution and env-loading logic (`resolveWorkspaceRoot`, `resolveStargateEnv`) so it doesn't silently fall back to `process.cwd()`.
- Define the long-term boundary between "Rockets SDK generic module patterns" and "Stargate-specific execution" so future modules don't have to hand-roll the same adapter every time.

## Out of scope
Any changes to the Stargate engine itself (lives in the sibling repo).