fix(deploy): truthful `unknown` revision state for canceled non-rollout Argo (don't lie about the cluster)

Problem

When a non-rollout Argo deploy is canceled or superseded, gocdnext does not force-abort the
external sync — so the apply may still converge on the cluster. Recording the deploy revision as
canceled (as if the change can't land) is a lie about the cluster state: history, "current
deployment", and DORA can diverge from reality, and under supersede an OLD deploy can even land AFTER
the new one.

deploy.Decide (server/internal/deploy/decide.go) handles cancel only for RolloutAware=true; a
non-rollout Argo deploy keeps converging and can finalize success today.

Proposed direction

Split the JOB status from the external RESULT into distinct revision states:

• canceled — reserved for positive knowledge the change did NOT / CANNOT land (rollout aborted
  before any target shifted; the job canceled before the sync/apply was issued).
• unknown (a.k.a. cancel_requested / superseded_unconfirmed) — the apply was already issued and
  may still converge (non-rollout Argo cancel/supersede): the JOB is canceled (we stopped waiting),
  the revision is unknown (cluster state unconfirmed).

Both canceled and unknown are excluded from DORA success/failure and never auto-become the
current deployment.

deploy.Decide matrix to implement + test:

• (i) non-rollout Argo cancel with the sync already issued ⇒ job canceled, revision unknown;
• (ii) rollout cancel BEFORE target shift ⇒ revision canceled;
• (iii) rollout "cancel requested, no known target, deadline elapsed" ⇒ canceled (no target shifted);
• (iv) supersede of a non-rollout deploy that may still land ⇒ unknown.

Migration: extend the deployment_revisions.status CHECK to add unknown (alongside canceled from
the cancel→canceled work); store model + FinalizeDeploymentRevision; Down handles existing rows.

Follow-up (optional): keep reconciling unknown to an observed terminal after job-cancel (a watcher
outliving the job) — v1 is the distinct state, not continued reconciliation.

Depends on: the deployment_revisions.status CHECK change from the cancel→canceled work.

Baseline: origin/main. Verify line numbers against current origin/main.

Start in server/internal/deploy/decide.go and trace the cancel and supersede paths for rollout and non-rollout Argo deploys. Then inspect the deployment_revisions status CHECK, the revision model, FinalizeDeploymentRevision, and the migration Down path. Done means the four listed cases produce the specified job and revision states, with canceled and unknown excluded from current deployment and DORA handling.