fix(workflows): four routes convert their own HTTPException into a 500, so a deliberate 404 reads as a server error #17653

Four routes convert their own HTTPException into a 500

Found while fixing #17014, which needed the guard on the routes it gave a 403. These four
are pre-existing and got no ownership check, so they were left out of that PR.

The shape, in autobot-backend/services/workflow_automation/routes.py:

    try:
        ...
        raise HTTPException(status_code=404, detail=ERR_WORKFLOW_NOT_FOUND)
    except Exception as e:
        logger.error(...)
        raise HTTPException(status_code=500, detail="Internal server error")

HTTPException is an Exception, so the route's own deliberate status is caught one line
later and replaced. A 404 the code raises on purpose reaches the client as "Internal server
error."

Enumerated with an AST walk over the file, not grep: the condition is a Try whose handlers
include Exception but not HTTPException, and whose body raises HTTPException.

Five routes in the same file already carry except HTTPException: raise, and #17014 added it
to the six it gave ownership checks. So the file already contains both the defect and its
remedy, which is what makes this a class rather than four bugs.

Why it matters beyond tidiness

• A client cannot distinguish "this workflow does not exist" from "the server broke".
• It hides future auth work. In workflows: owner_id is never recorded, so workflow control cannot be scoped to its owner (REST control is open to any signed-in user) #17014 present_plan was given a 403 and the swallow was
  still present, so the refusal came back as a 500 — a working ownership check that looked
  like a crash, and no test could assert it. That was caught only by enumerating this class.
  Any later 401/403/409 added to these four inherits the same trap.

Lineage

#10662 — "/agents/recommend swallows HTTPException(400) into a generic 500" — fixed this
exact defect at one route and closed. The class was never swept, so it is still here in
another file. Fixing the class once is the point of this issue.

Acceptance criteria

• Each of the four routes above re-raises HTTPException before its broad handler, so the
  status the code chose is the status the client receives.
• A guard fails when a route in this file has a try that raises HTTPException and
  catches Exception without re-raising it first. The AST condition above is the check;
  grep cannot express it.
• The guard covers the whole autobot-backend/ route surface, not just this file —
  fix(api): /agents/recommend swallows HTTPException(400) into a generic 500 #10662 shows a one-file fix does not hold.
• A test asserts a deliberate 404 from one of these routes arrives as 404.

Related

#17014 (found here), #10662 (same defect, fixed once at another route)