Handle deleted workflows and snapshot failures in API

[jmtdev0]

Description

This PR fixes the workflows REST API so failures from save_workflow/3 are
returned as proper HTTP responses instead of falling through as raw tuples and
crashing the Phoenix controller.

The controller now:

• Returns 404 Not Found when a workflow is soft-deleted between fetch and
  save.
• Returns 500 Internal Server Error when saving the workflow snapshot fails.
• Accepts both the current false snapshot failure value and the clearer
  :snapshot_failed value introduced by the related save-workflow work.

It also adds regression coverage and an Unreleased changelog entry.

Closes #4960

Validation steps

1. Run mix test test/lightning_web/controllers/api/workflows_controller_test.exs.
2. Confirm the workflow update tests report 57 tests, 0 failures.
3. Review the deleted-workflow case and confirm it returns 404 with
   errors: ["Not Found"].
4. Review the snapshot-failure case and confirm it returns 500 with a clear
   snapshot error instead of crashing the controller.

Validated with:

• mix test test/lightning_web/controllers/api/workflows_controller_test.exs
• mix compile --warnings-as-errors
• git diff --check

Additional notes for the reviewer

1. The root cause was the final tuple fallback in maybe_handle_error/3, which
   returned these unhandled failures unchanged. Phoenix controllers must return
   a connection or a valid response, so the raw tuple caused the request to
   crash.
2. The current save_workflow/3 implementation returns false for a snapshot
   failure, while the clearer :snapshot_failed atom is used by the related
   change discussed in PR AI-First Starting UX: Build from scratch #4918. Handling both keeps this fix correct for the
   current branch and forward-compatible with that naming improvement.
3. There is no separate POST regression test because POST and PATCH both pass
   through the same maybe_handle_error/3 clauses. Triggering a snapshot
   collision during creation would require artificial database setup and would
   test a different failure mechanism rather than a different controller
   contract. The two PATCH tests cover both distinct error responses directly.
4. The response choices follow the issue's suggested semantics: deleted
   resources return 404, while a snapshot persistence failure returns 500.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer)
  Not applicable: this PR only changes error handling after the existing authorization checks.
• I have updated the changelog.
• I have ticked a box in "AI usage"

This PR was developed by Codex with jmtdev0's supervision.

[jmtdev0]

Follow-up on CircleCI lint

After inspecting the failed lint job 98087, I made a small formatting-only adjustment to the new regression test. The test logic and production behavior are unchanged.

The new pipeline 98090 confirms that the formatting issue is resolved. The other PR-specific checks also pass:

• compile 98090
• test_elixir 98091
• check_dialyzer 98093
• test_javascript 98094

The remaining lint job 98092 fails only on credo, deps.audit, and hex.audit. I believe these failures are unrelated to this PR: Credo reports existing repository-wide suggestions, while the dependency audit findings concern packages already present in mix.lock, which this PR does not modify. The focused controller suite still passes locally with 57 tests and 0 failures.

This PR was developed by Codex with jmtdev0's supervision.