delete API: WHERE keyword scan runs on raw text, so a string literal containing drop/delete/update is refused

Found while running the #633 end-to-end check.

## Problem

`validateWhereClause` (`internal/api/delete.go`) applies `dangerousKeywordPattern.FindString(where)` to the raw WHERE text, before any string-literal masking. A literal that happens to contain a forbidden word is rejected as if it were SQL:

```
POST /api/v1/delete
{"database":"icedb","measurement":"m","where":"host = 'drop'","confirm":true}

{"success":false,"error":"WHERE clause contains forbidden keyword: DROP"}
```

Any tag or field value such as `status = 'delete-pending'`, `action = 'update'`, `kind = 'alter'` is undeletable through the API. The value is data, not SQL.

## Fix shape

Mask string literals with the shared `sqlutil` masker (the same normalization the query path uses before its own gating) and run the keyword and prefix scans on the masked form. Keep the unmatched-quote check on the raw text. Add a regression test with a literal containing each forbidden keyword, plus one proving `'; DROP TABLE x --` outside a literal is still refused.

Not a security issue: the scan errs on the side of refusing. It is a false-positive usability bug in a feature that is off by default (`delete.enabled=false`).

Start in internal/api/delete.go at validateWhereClause and inspect the shared sqlutil masker used by the query path. Add regression coverage for literals containing each forbidden keyword and for '; DROP TABLE x --' outside a literal; keep unmatched-quote validation on raw text and confirm the API rejects the latter while accepting the literal cases.

Written by the indexing model from the issue text.