Introduce incremental static type checking for Python core modules

[codeforester]

Goal

Turn Base's extensive Python annotations into an incrementally enforced correctness contract.

Background

Most production Python functions are annotated, but the repository does not run mypy or Pyright locally or in CI. An exploratory Python 3.10 mypy pass found a non-trivial baseline, confirming that annotations currently serve mainly as documentation.

This should be introduced as a ratchet across stable seams rather than as a blanket repository-wide gate with broad ignores.

Scope

• Choose and document mypy or Pyright for Base.
• Pin the tool in development dependencies.
• Add a repeatable local entrypoint and CI job.
• Start with stable typed seams such as base_cli, manifest/model modules, and GitHub Project operation protocols.
• Establish a no-new-errors policy for covered modules.
• Fix or narrowly document baseline incompatibilities in the first covered set.
• Document how additional packages graduate into the checked set.

Acceptance Criteria

• A documented local command runs the configured type checker reproducibly.
• CI checks the initial module set under Base's supported Python contract.
• Covered modules pass without a blanket ignore-errors setting.
• New type errors in covered modules fail CI.
• The staged expansion policy is documented.

Validation

• Run the new type-check entrypoint.
• Existing Python tests and Pylint.
• CI workflow contract tests if workflow metadata changes.
• git diff --check.

Non-Goals

• Do not gate all production modules in the first PR.
• Do not weaken runtime tests or Pylint.
• Do not add broad untyped or ignore-error escapes to manufacture a green result.

Project Fields

• Status: Backlog
• Priority: P2
• Size: M
• Area: Python
• Initiative: Contract Hardening

Agent Assignment

Human first for tool and baseline policy; subsequent package-ratchet slices can be agent-ready.