Drop stuck session when its workload pipeline finishes cleanly

When a CI workload finishes, the worker only acted on the drop action. A session still in created or running was left untouched, staying frozen until the cleanup cron reached it up to 60 minutes later. That is the frozen session users report.

This adds an elsif branch that marks those sessions as failed via drop, with a distinct summary. Because it routes through the existing UpdateWorkflowStatusService, the agent_platform_session_dropped event is emitted too, which makes the frequency of this state countable in production for the first time.

Per @tigerwnz (#608249 (comment 3680210827)), these count as failures: "something has gone wrong somewhere and the status should reflect that." That call is also why the spec assertion for the old no-op behaviour is replaced rather than kept.

Scoped to created and running only. drop is a legal transition from paused, input_required, and both approval states as well, and reconciling those would kill sessions that are legitimately waiting for a person.

Known race, not addressed here: the worker is data_consistency :delayed, so a stale replica read could in principle overwrite a session that had just finished. The pre-existing failed branch reads the same record, the status report lands before the CLI exits in the normal path, and retry is a legal transition out of failed. Ai::DuoWorkflows::CodeReview::TimeoutWorker uses data_consistency :always if a harder guarantee is wanted.

Testing: created and running are dropped, an already-finished session is left alone, and all four human-waiting states are untouched. The two reconcile examples were confirmed to fail with the fix removed.

Possible follow-up, unverified: ee/lib/gitlab/duo_workflow/sandbox.rb line 77 ends every workload script with echo "Command execution completed with exit code: $?", which prints the exit code but discards it. Whether that actually masks a failing job depends on whether the runner applies set -e, which needs a real job log to settle.

Related to #608249 (closed)