AggregatedMessageStream should expose invalid UTF-8 as a typed WebSocket error

## Summary

`actix_ws::AggregatedMessageStream` detects invalid UTF-8 in fragmented text messages, but exposes the failure as a generic `actix_http::ws::ProtocolError::Io`. Applications cannot reliably select the required WebSocket close code without matching an error string.

## Reproduction

Run the Autobahn fuzzing client against the `websockets/autobahn` example using `actix-ws` (Autobahn 25.10.1).

- Cases: `6.4.1–6.4.4`
- Input: invalid UTF-8 introduced in the middle of a three-frame text message
- Expected strict behavior: fail the connection with close code `1007` after detecting the invalid text
- Current result: the cases are reported `NON-STRICT`; the example receives a generic protocol/I/O error, logs it, and sends a normal close `1000`

## Likely cause

`actix-ws/src/aggregated.rs` validates the collected text with `ByteString::try_from(bytes)`, then converts the failure to `ProtocolError::Io(io::ErrorKind::InvalidData)`. The error loses the WebSocket-specific meaning (`invalid text` / close code `1007`).

## Suggested fix

Expose a typed invalid-UTF-8 WebSocket error, or provide a public error-to-close-code mapping, so handlers can respond with `CloseCode::Invalid` without parsing error strings. Preserve the existing continuation aggregation behavior. Add an `AggregatedMessageStream` regression test and retain Autobahn `6.4.*` as end-to-end coverage.

This is the `actix-ws` portion of [#1006](https://github.com/actix/actix-web/issues/1006). The malformed close-payload parser issue is tracked separately in [#4216](https://github.com/actix/actix-web/issues/4216).