fix(entities): match file-path entities case-insensitively

[anush-933]

extractEntities keeps file paths in their original case, but every other entity kind gets normalized. Since findEntityMatches compares with me.entity IN (...) and SQLite's IN on TEXT is case-sensitive, a memory that mentions src/Auth.ts never matches a query that mentions src/auth.ts.

I went with lowercasing the path at extraction time. Both recordEntities and findEntityMatches call extractEntities, so the two can't drift apart, and the index on memory_entities.entity still gets used. I skipped COLLATE NOCASE because it would force a scan on the retrieval path and would apply to every kind rather than just files. Nothing ever displays the entity string, so there's no display case to preserve.

Closes #26

Testing

npm run ci passes (234 tests). Added three tests to tests/entities.test.ts: lowercase normalization, mixed-case dedupe, and the repro from the issue. All three fail before the change and pass after.

I also ran npm run bench before and after the change and the output is identical, so there's no retrieval drift. bench:check does report drift against the committed snapshot, but it reports the same thing on a clean main, so I left bench/results/repo-memory.json alone rather than fold an unrelated snapshot update into this PR.

One question

This only fixes entities going forward. Rows already in an existing memory.db keep their old casing until that memory is re-recorded. I kept the change inside entities.ts since the issue scoped it that way, but I'm happy to add a migration that lowercases existing kind = 'file' rows if you'd rather have it here.

[vercel]

@anush-933 is attempting to deploy a commit to the vignesh's projects Team on Vercel.

A member of the Team first needs to authorize it.

[7vignesh]

Verified locally and green on Node 20/22 + CodeQL. The reasoning in your description is exactly right - lowercasing at extraction keeps the write and read paths in agreement without forcing a scan, and leaving the bench snapshot alone was the correct call since the drift pre-exists on main.

[7vignesh]

On the migration question: no need. Entities re-record whenever a memory is updated, and the entity leg is a recall booster rather than a correctness guarantee, so existing rows healing lazily is fine - not worth the migration risk. Appreciate you flagging it rather than assuming. Thanks for the clean fix!