Add immutable Monitor model

[halldorfannar]

Changes proposed in this PR

Fixes #470

Replace heterogeneous monitor dictionaries with a frozen, slotted Monitor dataclass that exposes typed geometry and
platform metadata attributes.

• Update the macOS, GNU/Linux, and Windows backends to produce and consume Monitor objects.
• Keep temporary string-key access for migration, while continuing to accept dictionaries and PIL-style tuples in
  grab().
• Preserve immutable monitor descriptions in the video demos by deriving separate dictionaries for cropped capture
  regions.
• Update filename formatting, examples, documentation, release notes, typing, and tests for the new model.
• Update AGENTS.md with instructions on how to update test_sdist when files are added, removed, or renamed.

This gives callers a stable, read-only monitor representation without preventing existing applications from passing
dictionary-based capture regions.

• Tests added/updated
• Documentation updated
• Changelog entry added
• ./check.sh passed

Validation: uv run ./check.sh. The full pytest suite was not run during the final review.

AI assistance disclosure

• AI assistance was used to generate this contribution.

Codex assisted with reviewing the implementation, identifying and implementing follow-up fixes in the demos and
ScreenShot initialization, updating the immutability test for static typing, running validation, and drafting this PR
description. The contributor reviewed and directed the API and capture-region decisions.

[jholveck]

I'm not really comfortable with this idea of making synthetic Monitor objects to send down through _impl.grab, rather than sending capture regions as dicts or tuples. Can you elaborate on why you made that choice?

[halldorfannar]

One overall thing. I'm wondering if the name CaptureRegion is too limiting. Maybe Region is better and more futureproof. It doesn't matter what the region will be used for inside MSS. It will always have the same coordinates associated with it. Using it directly for capture is just one application I can think of.

[jholveck]

One overall thing. I'm wondering if the name CaptureRegion is too limiting. Maybe Region is better and more futureproof. It doesn't matter what the region will be used for inside MSS. It will always have the same coordinates associated with it. Using it directly for capture is just one application I can think of.

Yeah, I think that Region may be better. For instance, we might use it in a Window object to give the window geometry to the user.

(Besides, as_capture_region felt a bit verbose; it was just the first thing that occurred to me when I wrote that comment.)

Food for thought: should a Region carry with it the metric space (nominal vs. physical)? Probably not practically, and definitely not in this PR, but it may be at least worth passing through the brain once.