Add planning-effort counters and prepare-stage timer to profile notes

[heunghingwan]

Builds on #15. When profile: true (with include_plan: true), the
existing stage-timing note in GqlExecutionExplain.notes also carries:

• a prepare stage timer, covering the GQL work between lowering and the
  published snapshot (order-by resolution, row-count evaluation, target
  configuration) — previously the only uninstrumented gap around the
  graph-row call;
• planning-effort counters: node_legal_universe_sources (legal-universe
  candidate sources enumerated across node plans), edge_source_consults /
  edge_source_misses (edge-source cost memo use), and
  secondary_index_followups (secondary-index read followups enqueued).

Why

The stage timers from #15 isolate the graph-row call as the dominant bucket
but say nothing about planning effort. These counters are a cheap
regression canary for planner work — they surface how many candidate
sources the planner evaluated, so a change that balloons enumeration (new
index types, planner refactors) is visible before it ships. Filling the
prepare gap also means the graph-row bucket is the only unexplained
stage, so its isolation is exact.

Design (same contract as #15)

• No public struct / connector changes — values ride the existing
  notes: Vec<String> line.
• Does not touch the shared read substrate (read.rs, query_exec.rs,
  ReadView/SourceList); the native hot path is unaffected.
• Counters are produced via a crate-local thread-local the planner
  increments and the GQL layer snapshots only when profiling.
• graph_row_plan_and_execute remains a single combined bucket; splitting
  it (plan vs probe vs execution) is intentionally out of scope here.

Overhead

profile: false is unchanged: the timer mark() returns None and
counter values are neither snapshotted nor surfaced. The planner always
increments the thread-local; measured fire count is 3–8 per query
(~22–57 ns on the default path, ~0.001–0.005% of read latency), confirmed
by reading the values back through the note.

Tests

New gql_query_profile_planning_counters_in_explain_note asserts the note
carries every counter/timer field, that a single-node query enumerates

=1 universe source, and that nothing is attached when profile is off.
cargo test --lib gql (358 tests) and cargo clippy --lib are clean.

[bhensley5]

Thanks for the follow-up. I reviewed this on top of #15 and the scope still looks right. It keeps the profiling data on the existing explain notes surface, avoids public/connector API changes, and adds useful planner-effort visibility.

Merging via squash.