Bad request instead of an actual error if error message contains html tags

### Bug description

When creating a chart, if error massage contains html tag, `Unexpected error Bad request` is shown instead of an actual error.
However `api/v1/chart/data` responds with the full error text in `message` which makes me think that it has something to do with the ui trying to prevent XSS attacks.
I tried to play with `HTML_SANITIZATION` but it seems that nothing changes.

**How to reproduce**
1. Create a new chart
2. Create a custom metric with `` in the expression
3. Press "UPDATE CHART"
4. If your db connector usually displays problematic query in the message error, instead of an actual error `Unexpected error Bad request` will be shown.

**Expected result**
`Unexpected error` and an actual error message returned by api in response like below
```
Unexpected error
Error: HTTPDriver for [your clickhouse host] received ClickHouse error code 62
Code: 62. DB::Exception: Syntax error: failed at position 37 ('<') (line 1, col 37): AS `My column_b77020`
FROM (select number from numbers(10)
) AS `virtual_table`
LIMIT 1000
FORMAT Native. Expected one of: expression with optional alias, element of expression with optional alias, lambda expression, CAST operator, NOT, INTERVAL, CASE, DATE, TIMESTAMP, tuple, collection of literals, array, number, literal, NULL, NULL, Bool, TRUE, FALSE, string literal, asterisk, qualified asterisk, compound identifier, identifier, COLUMNS matcher, COLUMNS, qualified COLUMNS matcher, function name, substitution, MySQL-style global variable, end of query. (SYNTAX_ERROR) (version [your clickhouse version] (official build))
```

- [ ] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

Reproduce the chart update with a custom metric containing `` and compare the UI error with the full `api/v1/chart/data` response. Trace the UI handling around `HTML_SANITIZATION` and the returned `message`; done means the chart displays the actual backend error while preserving XSS protection.

Written by the indexing model from the issue text.