list_tables/describe_table surface soft-deleted table tombstones with no way to distinguish them from live tables

## What to change

Add tombstone detection to the MCP tools that list or describe tables so agents can distinguish a live table from a soft-deleted one. Specifically:

- `list_tables` / `get_measurements` (`src/tools/categories/query.tools.ts:119,372` → `InfluxService.query.getMeasurements()` in `src/services/query.service.ts:695,718` for Core/Enterprise, `:634,666` for Cloud Dedicated/Clustered): the underlying query is a plain `SELECT DISTINCT table_name FROM information_schema.columns WHERE table_schema = 'iox'` (or `SHOW MEASUREMENTS`). Add a check for the deleted-at-timestamp suffix pattern (`-` or similar) and either exclude those rows or annotate them.
- `describe_table` / `get_measurement_schema` (`query.tools.ts:153,424` → `query.service.ts:952,1002`): currently returns full schema for a tombstoned table as if it were live, with no indication it's a dead remnant.

Minimum viable fix: don't suppress rows (a legitimate user table could end in a timestamp-shaped string), but add a `warnings` entry in the response when a suffix-pattern name is detected, e.g. `"warning: 'foo-20260723T173021' looks like a soft-deleted table tombstone, not a live table"`.

## Why

InfluxDB3's `DELETE /api/v3/configure/table` performs a soft delete by renaming the table to `-` rather than removing it. The renamed tombstone stays visible in `information_schema.tables`/`SHOW TABLES` indefinitely until a scheduled or immediate hard delete purges it — there is no API call that removes the tombstone directly (re-deleting it returns `409 Conflict`).

Confirmed live against a running InfluxDB3 Enterprise instance during MCP testbench e2e testing (see `influxdata/docs-tooling` testbench runs from 2026-07-23): an agent using `list_tables` and `describe_table` saw and fully described a table named `e2e_conditional_write_probe-20260723T173021` with no signal that it was a dead tombstone rather than a real table.

## Impact

Any agent using this MCP server to enumerate or describe tables can be misled by dead tombstones:

- An agent asked "what tables exist in this database" will include tombstones in its answer, giving the user a wrong count or wrong list.
- An agent asked to inspect schema for troubleshooting may waste tool calls describing a table that no longer holds live, queryable data.
- Test harnesses or automation built on top of `list_tables` that assert on exact table counts/contents will intermittently fail after any table delete, since the tombstone persists across the whole soft-delete-to-hard-delete window (which can be indefinite if `hard_delete_at` is never scheduled).

## Verification

1. Create a table, write a row, then `DELETE /api/v3/configure/table?db=&table=` (soft delete, default).
2. Call `list_tables` (or `get_measurements`) against that database — confirm the tombstoned name (`-`) is present.
3. Call `describe_table` (or `get_measurement_schema`) against the tombstoned name — confirm it currently returns a full schema with no warning.
4. After the fix: confirm `list_tables` response includes a `warnings` entry flagging the tombstoned name (or the row is excluded, per whichever approach is chosen), and `describe_table` on a tombstoned name likewise carries a warning.
5. Confirm a legitimately named user table ending in a timestamp-shaped string (e.g. `snapshot_20260101T000000`, created directly, never deleted) is NOT excluded or misflagged as a false positive.

Start in src/tools/categories/query.tools.ts at the list_tables/get_measurements and describe_table/get_measurement_schema entries, then trace their calls into the corresponding methods in src/services/query.service.ts. Verify the current responses against a soft-deleted table and a legitimately timestamp-shaped table, then confirm both tool paths report a warning for tombstone-shaped names without falsely flagging the live table.

Written by the indexing model from the issue text.