fix: API Server - Return 404 from /api/executions/{id}/state when execution does not exist

[AryanKansagara]

Closes #49

Problem

GET /api/executions/{id}/state (and its alias /api/executions/{id}/graph_execution_state) returns HTTP 200 for an execution id that does not exist in the database. The body looks like a finished, empty graph:

{"child_execution_status_stats": {},
 "child_execution_status_summary": {"total_executions": 0, "ended_executions": 0, "has_ended": true}}

Clients polling this endpoint cannot distinguish "the graph finished" from "this id does not exist". Every other lookup-by-id endpoint in api_server_sql.py, including the neighbouring /api/executions/{id}/container_state, returns 404 in this situation.

Cause

ExecutionNodesApiService_Sql.get_graph_execution_state builds its response by counting child ExecutionNode rows grouped by status. It never checks that the parent execution exists. For an unknown id the counts are simply zero, and zero ended out of zero total is reported as has_ended=True.

Fix

Add the same existence check that get_container_execution_state already performs, before any counting:

if not session.get(bts.ExecutionNode, id):
    raise errors.ItemNotFoundError(f"Execution with {id=} does not exist.")

api_router.py already maps ItemNotFoundError to a 404 JSON response, so no router changes are needed. The error message matches the sibling endpoint. Behaviour for existing ids is unchanged; a real graph node with no children still returns 200 with empty stats (covered by the existing test_no_children_returns_empty_stats).

Tests

• Added TestGetGraphExecutionState.test_missing_execution_raises_not_found in tests/test_execution_nodes_api_service.py, mirroring the existing test_missing_execution_still_raises_not_found for the container state endpoint.
• Full suite: 472 passed on Python 3.13.

Verification over HTTP

Against an empty SQLite database, before the change:

GET /api/executions/does-not-exist/state                  -> 200
GET /api/executions/does-not-exist/graph_execution_state  -> 200
GET /api/executions/does-not-exist/container_state        -> 404

After the change:

GET /api/executions/does-not-exist/state                  -> 404 {"message": "Execution with id='does-not-exist' does not exist."}
GET /api/executions/does-not-exist/graph_execution_state  -> 404 {"message": "Execution with id='does-not-exist' does not exist."}
GET /api/executions/does-not-exist/container_state        -> 404 {"message": "Execution with id='does-not-exist' does not exist."}

Things to be aware of

• Cost: one additional primary key lookup per call. This endpoint is polled by the UI, but the lookup is the cheapest query the database can run and get_container_execution_state already pays the same cost on every call.
• Behaviour change for clients: any client that treated the previous empty 200 as "not found" will now receive a 404. I could not find anything relying on the old behaviour, and the issue requesting the 404 was opened by the project lead, but flagging it for the tangle-ui maintainers in case their polling code needs to handle the new status.