fix(mcp): stop memory tool hangs from s-expression parser infinite loop

[bplatz]

Problem

memory_add (and memory_recall) on the fluree MCP server could hang forever — the tool call never responds and one tokio worker gets permanently pinned at 100% CPU. Bursts of 3+ concurrent adds made this near-certain, and each occurrence eats another runtime worker until the whole server starves. PR #1384's lock work is sound but was unrelated: all memory locks are 30s-bounded and can't produce an unbounded hang.

Root cause

Diagnosed on a live wedged v4.1.1 mcp serve process (12.7h of accumulated CPU) via sample/lldb: the spinning thread was re-trimming the same content slice starting with ) inside parse_s_expression_args.

The chain:

1. After every successful add, the related-memories lookup feeds the raw memory content back as a recall query.
2. recall_fulltext interpolates it into a (fulltext ?content "...") bind expression, escaping only " → \".
3. The s-expression parser had no escape support, so the string token ended at the first embedded quote, leaving the rest of the content as garbage tokens.
4. When the leftover text starts with ), parse_s_expression_args finds the delimiter at position 0, consumes zero bytes, and loops forever.

Memory content containing a double quote followed by a paren — routine for code-flavored insights — reliably wedges every v4.1.1 install. Reproduced end-to-end over MCP stdio with a single add.

Fixes

• Termination guard: an argument token that consumes no input is now a ParseError, guaranteeing the parse loop terminates on any malformed input (parse_s_expression_args, parse_s_expression_arg).
• Escape support: string literals honor \" and \\ throughout — quoted_string_end/unescape_string in filter_sexpr, the sexpr tokenizer, and find_matching_paren; find_matching_bracket is now also quote-aware. Unrecognized \x sequences are preserved verbatim.
• Proper interpolation: recall_fulltext escapes backslashes before quotes so arbitrary content round-trips through the parser.
• Init race: MemoryStore::initialize tolerates losing the create_ledger race — concurrent first-burst tool calls previously failed with Ledger already exists: __memory:main.

Testing

• New parser regression tests, including the exact wedge shape (stray ')' errors instead of looping, escaped quotes with parens, hostile fulltext round-trip)
• New store-level test: recall_fulltext with quote+paren+backslash content
• Full fluree-db-query lib suite (1,177), fluree-db-memory suite (64), and grp_query integration suite (299) pass; clippy clean
• Verified end-to-end against a rebuilt CLI over MCP stdio: 4 concurrent first-burst adds with hostile content + a hostile recall all succeed with idle CPU afterward (previously: no response, core pinned)

[aaj3f]

Grateful for this -- was going to investigate why I still saw the issue after the other PR merged, but this makes sense