feat: notifications list, read, mark-read, archive, and unarchive

[lightstrike]

Summary

• Add new top-level notifications command with list, read, mark-read, archive, and unarchive subcommands
• Enhance codegen to support GraphQL interface types (needed for Notification)
• Generate notifications, notification queries and notificationUpdate, notificationArchive, notificationUnarchive mutations
• Include offline tests (help output) and online tests (list + archive/unarchive round-trip)

Test plan

• cargo build --workspace compiles
• cargo clippy --workspace -- -D warnings clean
• cargo fmt --check passes
• Offline tests pass (7 new)
• SDK online tests pass (notifications_list, notification_archive_and_unarchive)
• CLI online tests pass (notifications_list_returns_json, notifications_archive_and_unarchive)

Note: Notifications are system-generated, so online tests work with existing notifications and skip gracefully if none exist.

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