fix(api): return 200 with embedded log on SAS session failure instead of 400

A failed session (e.g. SAS %abort;, or a non-zero JS/PY/R exit) is a
normal outcome of running arbitrary user code, not a request-shape or
server problem. The #388 fix stopped processProgram() from hanging
forever on a failed SAS session, but did so by throwing a
SessionExecutionError, which surfaced as an HTTP 400 with a bespoke
JSON shape - breaking Studio's log tab, which only renders on 2xx.

Align the SAS branch with the pre-existing JS/PY/R behaviour: resolve
instead of throwing, and let Execution.ts fold session.failureReason
into the log the same way it already does for a debug-mode run. This
removes the now-dead SessionExecutionError class and its try/catch
wrapper entirely.

Update the diagrams in api/docs/diagrams/ to match.

api/docs/diagrams/code-execution-overview.md

@@ -30,8 +30,9 @@ fresh per request inside `processProgram`.
   code into the session and drives it to completion/failure, per runtime.
 - `api/src/controllers/internal/Execution.ts` — `ExecutionController`,
   the entry point controllers call; acquires a session, calls
-  `processProgram`, reads back `log.log`/`webout.txt`/headers, builds the
-  HTTP response (or a `SessionExecutionError` on failure).
+  `processProgram`, reads back `log.log`/`webout.txt`/headers, and builds
+  the HTTP response. A failed session (any runtime) is embedded in that
+  same response, not thrown as a separate error.
 - `api/src/controllers/internal/create{SAS,JS,Python,R}Program.ts` —
   per-runtime code templating (wraps the user's submitted code with
   boilerplate: variable injection, `_webout` redirection, etc).