Use zigpy's mypy exclude generation tool for stricter types

[puddly]

This PR copies the zigpy python -m tools.regenerate_mypy_ignores tool for granular typing excludes. I've migrated us to pyproject.toml with ci and testing sections.

As a test, I've fixed a few small unreachable and invalid-type issues in this PR as well.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.41%. Comparing base (fd3fbb9) to head (268e0f2).

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #773   +/-   ##
=======================================
  Coverage   97.41%   97.41%           
=======================================
  Files          50       50           
  Lines       10419    10419           
=======================================
  Hits        10150    10150           
  Misses        269      269           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[TheJulianJES]

We may even just want to use uv sync here, similar to what’s done in the quirks repo. I think the GH CI from our shared workflow will already do this now, so might be good to keep the setup script in sync?

[TheJulianJES]

Nice!

[zigpy-review-bot]

Verified end-to-end.

• python -m mypy zha/ in a fresh worktree against mypy 2.1.0 returns Success: no issues found in 52 source files, vs 78 errors in 18 files on dev (fd3fbb9b). The per-module overrides codify existing debt with finer granularity than the previous global suppression list, which also lets new error categories (assignment, override, union-attr, attr-defined) trip mypy in modules where they aren't suppressed — meaningful net stricter.
• python -m tools.regenerate_mypy_ignores is idempotent against the committed pyproject.toml — re-running on the worktree produces no diff.
• The endpoint.py import fix is load-bearing: from zigpy import Endpoint actually raises ImportError (zigpy/__init__.py doesn't re-export it), so the previous form only resolved because it was TYPE_CHECKING-guarded. The new from zigpy.endpoint import Endpoint as ZigpyEndpoint is the right shape for mypy to actually resolve ZigpyEndpoint to a class.
• New direct enum imports (PanelStatus, ArmMode, ArmNotification, AlarmStatus, WindowCoveringType, ColorCapabilities, Options) all resolve to the same objects as the class-nested forms — pure annotation cleanup, no call-site behavior change.
• Pre-commit log confirms mypy ... Passed runs as a real check now (previously the isolated env had no zigpy/zhaquirks and every import collapsed to Any under ignore_missing_imports).

Optional / consider — cross-repo parity with zigpy/zha-device-handlers

The quirks repo already runs the lock-file pattern this PR introduces here, and has settled on a slightly more consistent shape:

1. uv sync in script/setup rather than uv pip install -e . --group testing. The PR commits uv.lock and uses uv run --frozen in pre-commit, but script/setup uses uv pip install, which doesn't consult the lock. So pre-commit runs against pinned versions while the rest of the venv is resolved fresh each setup. uv sync would honor the lock everywhere and pick up the new [tool.uv] default-groups = ["testing"] declaration in one command. Quirks script/setup already does this.

2. Add a uv-lock --check pre-commit hook. Quirks has:

   - repo: https://github.com/astral-sh/uv-pre-commit
     rev: 0.8.6
     hooks:
       - id: uv-lock
         args: ["--check"]

   Without it, a contributor bumping a dep in [dependency-groups] without re-locking won't get caught until uv run --frozen fails on someone else's machine.

3. .venv vs venv/. Minor: uv defaults to .venv and the quirks repo + the existing developer venv both follow that. The PR keeps the pre-existing explicit venv/ name; both are gitignored so it's harmless, but renaming to .venv would match the new uv-centric tooling and the sister repo.