refactor: split offline test suites into feature-organized submodules

[lightstrike]

Summary

• Split the two monolithic offline test files into feature-organized submodules for easier navigation and maintenance
• CLI offline (crates/lineark/tests/offline.rs, 64 tests) → 13 submodules: usage, issues, teams, projects, documents, cycles, milestones, embeds, comments, auth, self_update, format, labels
• SDK offline (crates/lineark-sdk/tests/offline.rs, 39 tests) → 2 submodules: queries, mutations
• Uses #[path] attributes since Rust integration tests don't follow standard edition 2021 module resolution for subdirectories (e.g. mod foo; in tests/bar.rs looks for tests/foo.rs, not tests/bar/foo.rs)

Scope

Only the two default-harness (offline) test files are split. The three custom-harness files (online.rs, blocking_online.rs) that use test_with::runner!/test_with::tokio_runner! + #[test_with::module] are left as-is — the include! pattern doesn't work with #[test_with::module] because the proc macro processes tokens before include! is expanded.

Test plan

• cargo test -p lineark --test offline — 64 passed
• cargo test -p lineark-sdk --test offline — 39 passed
• Test counts match original monolithic files exactly (verified via --list before and after)
• make check passes (fmt, clippy, doc, build)
• make test passes (all workspace tests)
• No changes to schema/operations.toml or generated code

[lightstrike]

@flipbit03 Let me know if you feel architecturally aligned on the intent of this PR. Noticed the test files were getting quite long. If this approach feels right, I'll dial in and get review ready. If not, please advise how you'd like to approach.

[flipbit03]

@lightstrike I'm in agreement to this strategy and I really think it is for the best - Since we have quite a bit in the pipeline already, let's first vet/approve/merge your other PRs and then I think this one is ready to be:

1. Rebased with all the new changes
2. Updated so that tests of the new (recently merged functionality) are also in line with the new folder structure.

Also, we should probably modify the CLAUDE.md with explanations on how to breakdown tests and the significance of the split between online/ and offline/ (that online is the true test, but is severely bandwidth limited, and needs to be run serially and slowly, one at a time)

[flipbit03]

@lightstrike PS: Also, it would be great if you allowed me to do quick edits on your contribution branches - This way, I'd be able to deliver some of these requested tweaks myself - specially if it's minor stuff, I can just jump straight in, and it might make for a more efficient async contribution experience. Thanks!

[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!