Fix literal subscriber search

[mherzog4]

Summary

Treat the subscriber search parameter as a case-insensitive literal substring across listing, count, CSV export, and bulk-action queries.

Root cause

The simple search value was passed directly to PostgreSQL’s ~* regex operator. In a valid subaddress such as user+subaddr@example.net, + is interpreted as a regex quantifier instead of a literal character, so searching for the exact email returns no rows. Other regex metacharacters can likewise change the meaning of a normal text search.

This replaces the regex comparisons with STRPOS(LOWER(column), LOWER(search)) > 0. The separate advanced SQL-expression query feature is unchanged, and this PR does not touch the admin frontend currently being replaced for v7.

Verification

• PostgreSQL regression check: the old comparison returned false for user+subaddr@example.net; the new comparison returned true
• Local GET /api/subscribers returned the seeded plus-address subscriber with total: 1
• Local GET /api/subscribers/export exported that subscriber
• Local PUT /api/subscribers/query/lists matched that subscriber and added the requested confirmed subscription
• go test ./...
• go vet ./...
• go build -o /tmp/listmonk-build ./cmd
• git diff --check

Closes #3167

AI disclosure

This contribution was developed with AI assistance (Codex).

[github-actions]

Issues Found

No issues found.

Summary

Total issues: 0 critical, 0 important, 0 minor.

Overall Verdict

Status: Patch is correct

Explanation: The diff cleanly replaces regex-based search on subscriber name/email with a case-insensitive literal substring check using STRPOS(LOWER(...), LOWER($n)) across the affected queries. The SQL remains syntactically valid and preserves the existing parameter/CASE logic without introducing new correctness or safety issues.

---

Review generated by Hodor (model: gpt-5.2)

Review Metrics — 6 turns, 5 tool calls, 41s

• Tokens: in 4.7K | cached 22.0K | out 2.2K (total 28.9K)
• Cost: $0.0422