releases cannot publish: the OAuth client secrets did not come across with the workflow

[phelian]

Tagging v0.119.0 built nothing: the release job refuses, correctly, with

FPCLOUD_OIDC_CLIENT_ID / FPCLOUD_OIDC_CLIENT_SECRET are not set on this repository.

The guard is doing exactly what it was written to do — a binary without the OAuth
client installs fine and fails only at fpcloud login, so refusing to publish is
right. The gap is that the extraction moved the release workflow here without the
secrets it depends on:

• fogpipe/cloud has FPCLOUD_OIDC_CLIENT_ID and FPCLOUD_OIDC_CLIENT_SECRET
  (both set 2026-07-29)
• fogpipe/cloud-cli has no secrets at all

What this means right now

The Go module tag resolves fine — go get github.com/fogpipe/cloud-cli@v0.119.0
works, and the platform has already bumped to it. So downstream is unblocked.

No binaries were published. fpcloud upgrade, Homebrew and Nix cannot see
v0.119.0, so the fixes in it — the platform host and config columns, and the
--watch token-expiry fix — are not installable by anyone.

Fix

Set both secrets on this repo from the same Google Desktop OAuth client the
platform uses, then re-run the failed v0.119.0 release run rather than
cutting a new tag: the version is already published as a module, and re-releasing
a version is what the upgrade/skew model must never see.

gh secret set FPCLOUD_OIDC_CLIENT_ID     --repo fogpipe/cloud-cli
gh secret set FPCLOUD_OIDC_CLIENT_SECRET --repo fogpipe/cloud-cli
gh run rerun <the failed v0.119.0 run> --repo fogpipe/cloud-cli

Worth deciding while you are here

Every future tag hits this until the secrets exist, and the failure is only
visible to whoever pushed the tag. A release that cannot publish should probably
be loud somewhere shared — the run already has a "Notify Release Failure" step,
so it may only need a destination.