enhancement: show cached table lease wait time in slow query and EXPLAIN ANALYZE

## Enhancement

Improve how cached table lock-lease waiting time is exposed in slow query logs and `EXPLAIN ANALYZE`.

## Problem

When a write statement targets a cached table, TiDB may spend significant time waiting for the cached table read lease to expire before it can switch to the write path.

Today this waiting time is difficult to identify from user-facing diagnostics:

- In slow query logs, `Query_time` can be much larger than the visible parse / optimize / KV / PD / 2PC timings.
- The log may only show `IsWriteCacheTable: true`, which hints at the cause but does not quantify the waiting time clearly.
- In `EXPLAIN ANALYZE`, the `execution info` for write statements does not make this phase obvious enough, so the time looks "missing" or gets mentally attributed to KV / commit.

This makes diagnosis harder for operators, especially when the statement itself is a small single-region write and the visible KV / commit path is only a few milliseconds.

## Expected behavior

The cached-table lease-wait phase should be surfaced explicitly and quantitatively in both places below:

1. Slow query log
2. `EXPLAIN ANALYZE` / runtime execution info for write statements

## Suggested improvement

Expose a dedicated field or phase for cached table lease waiting, for example:

- `Wait_lock_lease_for_cache_table`
- or another name consistent with existing slow-log / execdetails conventions

Suggested behavior:

- Print the exact wait duration in slow query logs whenever it is non-zero.
- Include the same phase in `EXPLAIN ANALYZE` execution info for `INSERT` / `UPDATE` / `DELETE` / `INSERT ... ON DUPLICATE KEY UPDATE`.
- Keep the existing `IsWriteCacheTable` signal if useful, but avoid making it the only clue.
- Make it easy to distinguish this time from KV RPC time, PD time, lock wait, and 2PC commit phases.

## Why this helps

This would make slow write diagnosis much more straightforward:

- Operators could immediately see that the latency comes from cached table lease waiting rather than TiKV write latency.
- The visible phase breakdown would add up more intuitively.
- It would reduce confusion when `Query_time` is far larger than the sum of the currently displayed sub-stages.

## Notes

I am intentionally not attaching the original slow log / SQL / plan details here because the motivating case comes from a production workload with sensitive identifiers. The issue is reproducible in principle without those details: any write to a cached table that has to wait for read lease expiration can show this diagnostic gap.