lazy init locked chromadb instance in wiki-search

[mikasenghaas]

Description

previously, wiki-search could not be loaded in processes on the same machine without deadlocking because it eagerly created a local chroma instance with locks. now, the chroma instance is only initted on first tool call. this allows multiple instances to at least exist (e.g. prime-rl orchestrator loads to obtain dataset + env worker loads to execute env)

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Test improvement

Testing

• All existing tests pass when running uv run pytest locally.
• New tests have been added to cover the changes

Checklist

• My code follows the style guidelines of this project as outlined in AGENTS.md
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published

Additional Notes

---

Note

Introduces lazy ChromaDB setup to prevent startup lock contention and enable multiple concurrent wiki-search env instances.

• Replace eager Chroma client/collection creation with _get_collection that initializes once per process and calls _init_chroma on first use
• Initialize collection on first search_pages call; query concurrency still guarded by _get_chroma_semaphore
• Bump version to 0.1.22 and add README changelog entry documenting the change

^{Written by Cursor Bugbot for commit c341760. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}