feat: documents search and projects search commands

[lightstrike]

Summary

• Add searchDocuments and searchProjects queries to operations.toml and regenerate SDK
• Add blocking client wrappers for both search queries
• New CLI subcommands:
  • lineark documents search <QUERY> [-l N] [--team KEY] — full-text search across documents
  • lineark projects search <QUERY> [-l N] [--team KEY] — full-text search across projects
• Follows the established searchIssues pattern with lean types, table output, and team filtering
• Add DocumentGuard RAII struct and retry_search_with_backoff helper for online tests
• Update lineark usage reference

Test plan

• cargo fmt --check — clean
• cargo clippy --workspace -- -D warnings — clean
• cargo test --workspace — all offline tests pass (80)
• CLI online tests pass: basic search, create-then-find with retry, --team filter
• Manual smoke: documents search, projects search, team filter all work
• SDK online tests blocked by feat: make test team configurable via environment variable #105 — pre-existing test panics and aborts the test_with runner before new tests execute

Blocker: #105 must be resolved for the full SDK online test suite to run.

[flipbit03]

Hey @lightstrike — thanks for your enthusiasm and all these contributions! We just released v2.0.0 which includes several of your earlier contributions — great work!

Quick heads-up on workflow: with multiple draft PRs open at once, they tend to go stale fast as main moves forward and earlier PRs get merged (causing conflicts in later ones). Looking at our recent merged PRs (#88, #91, #92, #106, #107, #108, #112), I had to push 30+ commits across your branches — merge conflict resolution, rebasing on main, reworking implementations, fixing tests, updating docs — on top of your original work. I'm happy we got all of that shipped together, but that level of serial branch maintenance isn't sustainable on my end going forward.

To keep things smooth, it'd be great if you could pick the one you'd like to land first, rebase it on the latest main, and mark it as ready for review. Once that's merged, move on to the next one, and so on. That way each PR is up to date and reviewable, and we avoid a pile-up of conflicts.

Also, going forward — for PRs that involve design or architectural changes, please open an issue first so we can discuss the approach before code is written. That way we align on direction early and avoid wasted effort on both sides. (See #115 → #126 → #127 as an example of how that played out.)

Tag me (@flipbit03) when it's ready for review. Looking forward to it!