feat(shorebird_cli): add patches rollback / rollforward

[bdero]

Summary

Adds CLI surface for the rollback and rollforward patch operations that
were previously dashboard-only. Both invocations are single network calls
gated by a pre-flight is_rolled_back check so the no-op case prints a
helpful message instead of relying on the server's 304 response.

shorebird patches rollback    --release-version 1.0.0+1 --patch-number 1
shorebird patches rollforward --release-version 1.0.0+1 --patch-number 1

Both accept --app-id / --flavor and the global --json flag.

Why

The HTTP endpoints have existed for a while, but the only way to invoke
them today is through the dashboard. Two recent uses of these operations
have been workflow-friction:

1. Reproducing bug: checkForUpdate reports upToDate after patch-to-release rollback (regression of #3206) #3728 end-to-end against a real
   device required scripting raw curl calls against api.shorebird.dev
   in a side repo, because the dashboard isn't scriptable.
2. CI pipelines that want to roll back a bad patch automatically (canary
   regression detected, kill-switch flipped, etc.) have to roll their own
   HTTP client + token handling.

A CLI command is the natural shape for both.

Implementation

Three layers, mirroring the existing patches set-track shape end-to-end.

Layer 1 — shorebird_code_push_client

New rollbackPatch / rollforwardPatch methods on CodePushClient that
POST to:

/apps/<id>/releases/<id>/patches/<id>/rollback
/apps/<id>/releases/<id>/patches/<id>/rollforward

Both treat HTTP 304 Not Modified (the server's "already in target state"
response — see code_push_server/routes/.../rollback.dart) as success, so
the call is idempotent at the client level too.

Layer 2 — code_push_client_wrapper

Wraps each with the standard logger.progress + _handleErrorAndExit
pattern, matching promotePatch. An optional patchNumber parameter
feeds into the progress label since the caller usually has it on hand
("Rolling back patch 5" reads better than "Rolling back patch").

Layer 3 — RollbackCommand / RollforwardCommand

Registered under the existing patches command group. Each pre-checks
is_rolled_back from getReleasePatches before issuing the POST so:

• Trying to roll back an already-rolled-back patch prints
  Patch 1 is already rolled back and exits with usage error, instead of
  silently 304-ing and printing success.
• Same shape for rollforward against an already-active patch.

--json envelope on success:

{"release_version":"1.0.0+1","patch_number":1,"action":"rollback"}

(action distinguishes the two commands for callers that machine-read.)

Naming + flag conventions

• Command names rollback / rollforward match the HTTP endpoint paths,
  the server-side filenames, and the dashboard JS client's rollBackPatch
  / rollForwardPatch methods. The dashboard UI labels them "Rollback"
  and "Roll Forward" but everything below the UI uses the single-token
  forms.
• Flags use --release-version (via CommonArguments.releaseVersionArg)
  and --patch-number, matching patches info (feat(shorebird_cli): add patches list/info; --json for set-track #3740). The older
  patches set-track uses --release / --patch which is a pre-existing
  inconsistency; this PR doesn't propagate it into new commands.

Test plan

• dart analyze clean across all changed files.
• dart test green:
  • code_push_client_test.dart — request shape, 204 + 304 success paths,
    unknown-error path, structured-error-response path. 8 cases.
  • code_push_client_wrapper_test.dart — progress success + failure for
    both verbs, optional patchNumber label. 5 cases.
  • rollback_command_test.dart / rollforward_command_test.dart —
    validation failure, --app-id override, missing patch,
    already-in-target-state, success, fetch-failure (text + json),
    POST-failure (text + json), JSON envelope shape on each branch.
    30 cases.
• Smoke-tested end-to-end against the real api.shorebird.dev while
  reproducing bug: checkForUpdate reports upToDate after patch-to-release rollback (regression of #3206) #3728: rollback returns 204,
  device picks up the rollback signal on the next poll, then rollforward
  returns 204 and the device's auto-update thread either reinstalls
  (rc2 / fixed) or refuses (rc1 / broken) the patch as expected.
• shorebird patches --help lists the new subcommands; each
  --help renders the flag table with (mandatory) annotations.

Refs

• Issue: bug: checkForUpdate reports upToDate after patch-to-release rollback (regression of #3206) #3728 (the bug whose reproduction
  motivated this CLI surface)
• Most recent precedent: feat(shorebird_cli): add patches list/info; --json for set-track #3740 (patches list / patches info)
• Related infra: code_push_server's
  routes/api/v1/apps/[appId]/releases/[releaseId]/patches/[patchId]/rollback.dart
  and rollforward.dart

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[nickshorebird]

LGTM overall - Two nits for behavior. Thanks for putting this together.

[nickshorebird]

Take it or leave it - End state is the same is the same on success or hitting this route. Returning a non zero exit suggests that something went wrong even though the end state is correct. Consider adding some flag IE --require-change, I am awful at naming to please feel free to change it, if you want the behavior to be there on default or non default. Changing to this would also match other CLI tool behaviors. This is in line w/ current set-track behavior hence take it or leave it.

[nickshorebird]

Take it or leave it - Consider printing the patch object similar to patches info on rollback and rollforward. Would reduce the need to do follow up patches info call.