fix(deploy): activate the release and application after deploy (DEVX-539)

[smukherjee-godaddy]

Problem

gddy application deploy bundled and uploaded extension artifacts but never activated anything — it ended after the extension loop. As a result every app deployed with the Rust CLI stayed INACTIVE and could not be enabled, so a deploy was effectively a no-op. Broken for both the extension path and the no-extension path.

Fix

Ports the TS deploy behavior (PR #77):

• ApplicationClient — add activate_release(applicationId, releaseId), mirroring the ActivateRelease GraphQL mutation ($applicationId: ID!, $releaseId: ID!).
• deploy_command — after the extension loop and regardless of extension count, call activate_release then update_application(status: ACTIVE), streaming release.activate and application.activate step events, and reporting status_after: ACTIVE on the terminal deploy step.

Order matters: the release is activated before the application is set ACTIVE.

Impact

• Deploy with 0 extensions → app ends ACTIVE.
• Deploy with ≥1 extension → app ends ACTIVE.
• The deployed release is actually usable/enable-able instead of stranded.

Testing

• New httpmock test: activate_release sends both IDs and returns the response data.
• cargo test / cargo clippy --all-targets -- -D warnings / cargo fmt --check — all clean.
• The full end-to-end deploy-flow integration test (T1 — mock credential + streaming) is deferred to the test-layer ticket; this PR covers the new client method directly and the wiring is a small, readable addition.

Context

Part of the Track A "ship an app" golden path. The terminal streaming result/error event for deploy --follow (DEVX-544) builds on this activation step.

[smukherjee-godaddy]

Closing as superseded by #103, which has already merged the same release activation and application promotion flow into rust-port with broader client-level test coverage.