Fix quote matching in meeting name search

[sblack4]

Fixes code4recovery/oiaa-direct#28

Problem

Search doesn't match meeting names when the only difference is between straight quotes (" or ') and curly quotes ("" or ''). For example, searching for "Joe's Place" wouldn't match "Joe's Place" in the database.

Solution

Transform search queries to match both straight and curly quote variants using character classes in regex patterns.

Implementation

• Add makeQuoteFlexibleRegex() function that:
  • Escapes regex special characters
  • Replaces quotes with character classes (e.g., Joe's → Joe['']s)
• Update pipelineFromQuery to transform nameQuery before regex matching
• Add test cases for quote handling and regex escaping

Example

• User searches: Joe's (straight apostrophe)
• Backend creates regex: Joe['']s
• Matches both: Joe's (straight) and Joe's (curly) ✓

Benefits

• ✅ No database migration required
• ✅ Works with existing data immediately
• ✅ Simple, focused change
• ✅ Easy to rollback if needed

Testing

• Added unit tests for quote transformation
• Existing tests still pass (simple strings unchanged)

[tim-rohrer]

Any idea why the version in package-lock.json updated? Not that it is wrong, but it seems odd that some contributions lead to the file being updated, and others don't.

[sblack4]

Update before merging — caught a bug in my own work:

The character classes I wrote ([''] / [""]) rendered as straight+curly in my editor but were actually duplicate ASCII bytes (5b 27 27 5d / 5b 22 22 5d). Regex dedupes those, so the function was effectively a no-op for curly input. The tests I added didn't catch it because they asserted toStrictEqual on pattern strings — both sides had matching ASCII bytes, so the test agreed with the broken implementation.

Commit 94eb178 fixes this:

• stringUtils.ts now uses explicit ‘’ / “” escapes — source bytes are unambiguous regardless of font/autocorrect.
• New stringUtils.spec.ts exercises real RegExp.test() behavior on both quote variants — would catch this class of bug.
• Removed two pipeline-level tests that were either the broken no-op assertion or redundant with the new spec / existing nameQuery wiring tests.

Re: the package-lock.json version bump — package.json on main is already at 0.16.0-alpha (commit 74087c6); the lockfile had drifted to 0.4.0-alpha. npm install during this PR synced it. Unrelated to the fix itself, harmless side effect.