perf(hooks): restore the in-memory fast path for trajectory lookups

#3467 made loadPendingTrajectory() always do two DB reads (completed +
pending) before returning, even when the trajectory is already tracked
cleanly in-process — turning every trajectory-step/post-task call into
a synchronous round-trip instead of a Map lookup. CI's
graph-trajectory-hooks-smoke (ADR-130 P3, <200ms budget) failed once on
a loaded runner at 1171ms; local runs stayed at 20-46ms, so this was
likely a transient load spike, but the always-hit-disk path was real
overhead regardless. Skip both reads when the id is already a clean
(non-dirty) in-memory hit — the case #3467 didn't change (same-process,
not-yet-restarted). The disk-recovery path #3467 added still runs
exactly when it's needed: on a cache miss (e.g. after an MCP restart).

v3/@claude-flow/cli/src/mcp-tools/hooks-tools.ts

@@ -545,6 +545,12 @@ async function persistPendingTrajectory(trajectory: TrajectoryData): Promise<boo
 }
 
 async function loadPendingTrajectory(id: string): Promise<TrajectoryData | undefined> {
+  // Fast path: a clean (successfully checkpointed) in-process record was written
+  // by this same call chain (trajectory-start/-step) and cannot yet have been
+  // completed elsewhere in the same synchronous request. Trust it without a
+  // round-trip — ADR-130 Phase 3's <200ms-per-call budget depends on this;
+  // only a cache miss (e.g. after an MCP restart) pays for the disk check.
+  if (!dirtyTrajectories.has(id) && activeTrajectories.has(id)) return activeTrajectories.get(id);
   try {
     const { getEntry } = await import('../memory/memory-initializer.js');
     // A completed record is authoritative even if pending-record cleanup failed