[Feature]: Add Fulltext2 JSON predicate index probe for current reads

在 official main `aa7b969f55e655f3f201fd3337589d070f994494` 上，`FULLTEXT2 ... WITH PARSER json` 的 JSON 比较能返回正确结果，但普通当前读的计划始终没有加入预过滤索引路径。

最小场景：

```sql
SET experimental_fulltext2_index = 1;
CREATE TABLE t(id BIGINT PRIMARY KEY, j JSON);
-- 写入包含 {"foo":"needle"} 的数据
CREATE FULLTEXT2 INDEX ft ON t(j) WITH PARSER json;

EXPLAIN SELECT id FROM t
WHERE json_extract_string(j, '$.foo') = 'needle';
```

三个独立的新会话中均得到：

```
Table Scan on ...t
Filter Cond: (json_extract_string(t.j, '$.foo') = 'needle')
```

实际谓词结果正确；对照查询 `MATCH(j) AGAINST('needle' IN BOOLEAN MODE)` 在同一表上会生成 `Table Function on fulltext2_search`。测试表为先建索引、后写入的 10,000 行数据，ISCP 任务 `index_ft` 为 live 且 completed，并已有非空 watermark；等待 tail 收敛后重复仍是同样计划。

文档 `test/distributed/cases/fulltext2/fulltext2_json_probe.sql` 的注释说明优化器会将 `json_extract_string/json_extract_float64` 比较转为 index probe，但该用例只校验结果等价，没有校验实际计划，因此未覆盖该问题。

初步代码观察：`pkg/sql/plan/apply_indices_fulltext_json.go:indexCoversSnapshot` 仅在 coverage 判定为真时添加 probe；`pkg/fulltext2/plugin/coverage/coverage.go:CoversSnapshot` 要求 `mo_iscp_log.watermark >= txn.SnapshotTS()`，且内部读取使用该查询事务。对于已完成的异步维护，watermark 来自更早的维护事务，而新的普通读快照通常更晚，条件可能持续 fail-closed。请确认该时序是否使 JSON probe 在当前读中不可达，或应采用可证明安全的覆盖判定方式。