#21016: Fix memory_forget candidate IDs to prevent deletion retry loop

## Summary This fixes a failure loop in `memory_forget`: - `memory_forget(query=...)` returned candidate IDs truncated to 8 chars in human-visible output. - The follow-up call requires `memoryId` to be a full UUID. - The agent repeatedly copied the truncated ID from tool output, which failed UUID validation, and retried without progress. Result: memory deletion often failed in practice even when the right candidate was found. ## Root problem `memory_forget` had a mismatch between: - **What it displayed** as the next-step identifier (8-char ID prefix), and - **What it accepted** for deletion (full UUID only). That mismatch produced repeated tool errors during autonomous loops because the model naturally reused the visible ID it was given. ## What changed - Updated `memory_forget` candidate output to display full IDs inline (instead of 8-char prefixes). ## Files - `extensions/memory-lancedb/index.ts` ## Options evaluated ### Option 1 (implemented): show full IDs in candidate output Pros: - Directly resolves the failure loop by making output immediately reusable as `memoryId`. - Very small and low-risk change. - No behavioral expansion in delete semantics. - No ambiguity/collision handling needed. Tradeoff: - Slightly longer output lines. Note on context impact: - Showing full IDs adds only **marginal** extra context tokens. - That additional verbosity is limited to the **memory deletion candidate flow** (`memory_forget` disambiguation), not the primary memory recall workflow (`memory_recall`), so normal recall behavior/context footprint is unchanged. ### Option 2 (not implemented): accept truncated/prefix IDs in `memory_forget` This would require expanding delete semantics to support prefix resolution, including: - Distinguishing full UUID vs prefix input. - Prefix lookup across candidate IDs (or DB-backed ID search). - Exact-match precedence rules. - Prefix-length guardrails (e.g., minimum length). - Ambiguity handling when multiple IDs share a prefix. - Clear deterministic error paths for: - no matches, - ambiguous matches, - invalid formats. - Additional tests across all branches above. Option 2 is feasible, but it introduces materially more logic and edge-case behavior than needed to solve the immediate reliability issue. ## Why option 1 Option 1 fixes the operational bug at its source (tool output/input mismatch) with minimal code and risk, and prevents the observed repeated-error behavior without broadening deletion behavior. ## Validation - `pnpm lint` passed - `pnpm vitest run extensions/memory-lancedb/index.test.ts` passed