feat(mem_wal): observe flush latency through the metrics facade

[hamersaw]

What

WriteStats tracks flush counts and cumulative time, but a running total cannot be resampled into a distribution — the individual observations are gone by the time anything polls it. An embedder can compute an average and nothing else, which is the wrong shape for latency: a flush pipeline is judged on its tail, not its mean.

This observes each flush individually through the metrics facade that lance-io already uses for object store operations. Observations route to whatever Recorder the embedding process installed, so this crate takes no position on the exporter, and the emit sites compile away with the feature off.

Shape

lance_mem_wal_flush_duration_seconds{kind="wal"|"memtable"} — one family with a label rather than two, because the WAL buffer flush and the memtable flush are stages of the same write pipeline and get read together. They differ by orders of magnitude, hence bucket bounds spanning a single object-store round trip through a multi-second dataset write.

Counts and byte totals stay on WriteStats: cumulative values lose nothing to sampling, so there is no reason to route them through a recorder.

Notes

• New dataset/mem_wal/metrics.rs, mirroring lance_io::object_store::metrics (name constants, bucket bounds, a describe_metrics an exporter calls after installing its recorder).
• Two emit sites, in WriteStats::record_wal_flush and record_memtable_flush, where the individual duration is already in hand.
• metrics becomes an optional dependency of the lance crate; the existing metrics feature now enables it alongside lance-io/metrics.
• Compiles with the feature on and off; mem_wal tests pass both ways.

[xuanyu-z]

@claude review once