[ybai08]

Fixes #209.

When the post-request script failed, send_http_request, send_ws_request and send_mqtt_request returned the error with ? before the lines that set is_pending = false and replace the cancellation token. The TUI then kept the request pending, and pressing send again only cancelled a token nobody was waiting on, so the request stayed stuck until ATAC was restarted.

The script's console output was also dropped on that path, so the (CONSOLE) POST-SCRIPT ERROR message pointed at an empty console, or at the output of an earlier run.

Changes:

• handle_post_request_script now returns the console output next to the result, so it is kept when the script fails (the same way handle_pre_request_script keeps the pre-request output).
• The HTTP, WebSocket and MQTT senders mark the request as finished and store the console output first, then return the script error.
• atac request send --console prints the post-request console output when the script fails, like it already does for a failing pre-request script.

Tests: one #[tokio::test] per protocol (failing_post_request_script_does_not_leave_the_request_pending). HTTP uses a one-shot local TcpListener that answers 200. WebSocket and MQTT connect to a closed local port, so the script runs on the error response. Each test checks that the request is no longer pending and that the console output contains the script error. All three fail on main with assertion failed: !request.is_pending.

What was run:

• cargo test: 40 passed (37 before plus the 3 new ones).
• cargo clippy --all-targets: same warning count as main (291). The existing digest.rs:381 string-indexing error is on main too.
• CLI against a local python3 -m http.server, with a post-request script that throws: atac -d <dir> request send c/r --console --dry-run now prints the JavaScript error before (CONSOLE) POST-SCRIPT ERROR. On main it printed only the error line.

Not run: the TUI by hand. The tests cover the request state the TUI reads (is_pending, console_output).

Not covered here: two other early returns leave a request pending the same way, and this PR does not change them. One is a WebSocket upgrade the server refuses (for example a 404 answer). A local check gave websocket upgrade failed with is_pending still true. The other is CouldNotDecodeResponse in the HTTP sender. Both can go in a follow-up if wanted.