chore(dashboard): bump rivet-gg/cloud and adopt sdk connection token endpoint

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #5413 feat(cli): pipe deploy runner config flags to managed pool r …
• #5412 feat(dashboard): show connection token inline with get-or-cr …
• #5410 chore(dashboard): bump rivet-gg/cloud and adopt sdk connecti … 👈
• #5411 feat(dashboard): add connection token issuing ui
• #5409 feat(dashboard): allow typing cpu value in compute tab
• #5408 feat(dashboard): add compute tab to namespace settings drawe …
• #5414 docs(compute): remove beta label from rivet compute
• #5407 fix(container-runner): report crashed child exits as errored …
• #5406 feat(rivetkit): report actor run() errors to the engine as e …
• main

Get stack: forklift get 5410
Push local edits: forklift submit
Merge when ready: forklift merge 5410

_{change uqlvksts}

[claude]

Review

Small, well-scoped chore PR: bumps the @rivet-gg/cloud preview package to build @466 (now consistent across frontend/package.json, root package.json, and the lockfile — previously frontend/package.json was pinned to @369 while root/lockfile pointed at e5c4911) and swaps the connection-token mutation over to the newly-available SDK method.

What changed

• mutationFn in createConnectionTokenMutationOptions (frontend/src/app/data-providers/cloud-data-provider.tsx) now calls parent.client.namespaces.createConnectionToken(project, namespace, { org }) instead of hand-rolling a fetch to the cloud API with credentials: "include" and manually checking response.ok.
• Removes the stale TODO comment that explained the previous workaround.

Code quality

• The new call matches the existing sibling patterns in the same file (createSecretToken, createPublishableToken), so this is a good consistency win rather than a one-off shortcut.
• Confirmed the SDK client (createClient() at the top of the file) sets withCredentials: true in its shared fetcher, so the cookie-based auth behavior from the old manual fetch call is preserved — no regression there.
• The consumer (ConnectionTokensInner in tokens.tsx) reads data.token / data.expiresAt directly off the mutation result, same shape as before, so this looks like a drop-in replacement.

Minor observations (not blockers)

• Error handling changes implicitly: previously a custom Error was thrown with an explicit HTTP status in the message; now whatever error the generated RivetClient throws propagates instead. Since sibling token mutations already rely on this same implicit behavior, this is consistent with existing conventions, but worth a quick manual check that the SDK's thrown error still produces a reasonable message in the {error.message} UI branch in tokens.tsx.
• The version bump points at a pkg.pr.new PR-preview tarball (@rivet-gg/cloud@466) rather than a published npm version. This is a pre-existing pattern in the repo (not introduced by this PR), but it's worth calling out since these preview builds can be ephemeral/pruned upstream — just flagging for awareness, not a request to change scope here.

Test coverage

• No tests included, but this is a thin plumbing change (swap a hand-rolled fetch for a generated SDK call) with no new branching logic, so that seems reasonable. Manual verification that "Issue Token" still returns a token + expiry in the dashboard (cloud flavor) would be the main thing to confirm before merge, since this touches an actual network call path.

Security

• No concerns. The change narrows the manual fetch/URL-construction surface in favor of a generated client, which is generally a security-positive simplification (removes hand-built URL string interpolation).

Overall this looks like a clean, low-risk cleanup once the corresponding SDK version ships the endpoint. Nice catch also unifying the three previously-inconsistent @rivet-gg/cloud pins.