Memory resolver treats incidental cwd: prose as a project path and suppresses real environment fallback #4163

Current main 976aa714ef3e19174dc0cb586cee7b20d064e4ef resolves the wrong memory project when ordinary trusted instructions mention the text cwd: before a real client environment block.

Actual request-shape reproduction:

body = {"system": "When describing cwd: use the actual environment path.", "messages": [{"role": "user", "content": "<env>\nPrimary working directory: /work/project-alpha\n</env>"}]}

Call the production extract_system_prompt(body), then ProjectResolver.resolve(RequestContext(headers={}, system_prompt=..., base_user_id="repro")).

Observed: the real environment block is omitted and the selected display name is use the actual environment path., not project-alpha. _extract_cwd_from_system_prompt accepts a substring anywhere in prose, and extract_system_prompt uses substring presence to decide that trusted cwd was already found. That redirects project-store selection instead of only failing to find a cwd.

Expected: recognize the documented cwd lines (including Claude's indented - Primary working directory: line), not incidental inline prose or quoted examples. Preserve genuine trusted-system precedence over user fallback and explicit header/CLI override precedence.

Distinct from #3429: this fails with only one system block and concerns false signal parsing, not missing a later system message. Observed with the real installed library on Linux/Python 3.13.14; no provider request, memory content or user directory was accessed. Targeted issue/PR searches found no competing cwd-prose parser fix.