Webserver and appproxy handlers return HTTPException objects instead of raising them

## Objective

Raise HTTP exceptions from the webserver and appproxy aiohttp handlers instead of returning the exception object as the response. Follow-up to BA-7625, which did the same for the manager.

## Background

Returning an HTTPException is deprecated since aiohttp 3.0 (#2415) and breaks on aiohttp 4 master, where HTTPException no longer subclasses Response: the server fails with AttributeError: object has no attribute prepare and answers 500. Remaining sites: web/server.py (10), web/proxy.py (8), appproxy/coordinator/api/proxy.py (1), appproxy/worker/api/setup.py (1). The appproxy exception middlewares rewrite every non-BackendAIError HTTPException other than 404/405 into GenericBadRequest, so raised redirects need to pass through them, as done for the manager in BA-7625.

## Acceptance Criteria

- No aiohttp handler or middleware in web/ or appproxy/ returns an HTTPException instance.
- Responses seen by clients (status, headers, body) are unchanged.
- Raised redirects in appproxy reach the client as redirects, not as a generic 400.

## Related

BA-7625 (manager).

JIRA Issue: BA-7631

Start with the listed handlers in web/server.py, web/proxy.py, appproxy/coordinator/api/proxy.py, and appproxy/worker/api/setup.py, then compare the manager change from BA-7625. Check the appproxy exception middlewares, especially redirect handling. Done means no handler or middleware returns an HTTPException, while client status, headers, body, and raised redirects remain unchanged.

Written by the indexing model from the issue text.