Fix matrix exponentiation type annotations

[Kanika0306]

Describe your change:

Fixes a NameError in Python/maths/matrix_exponentiation.py caused by self-referential type annotations in the Matrix class.

The Matrix.__mul__ method references Matrix in its parameter and return type annotations before the class definition has been fully evaluated. This causes Python to raise NameError: name 'Matrix' is not defined when the module is imported.

This change adds from __future__ import annotations to postpone the evaluation of type annotations, allowing the self-referential Matrix annotations to be resolved correctly without changing the algorithm's behavior.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Add or change doctests?
• Documentation change?

Fixes #15075

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms include at least one URL that points to Wikipedia or another similar explanation.
• If this pull request resolves one or more open issues then the description above includes the issue number(s) with a closing keyword: "Fixes #ISSUE-NUMBER".

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Kanika0306]

@cclauss kindly review

[cclauss]

This is not needed on a Python 3.14-only codebase.

[Kanika0306]

ok I will ccorrect that

[cclauss]

@priya-sundaram-dev, your review, please.

[priya-sundaram-dev]

Reviewed and tested locally — this is a solid, correct change. Nice work @Kanika0306.

graphs/kahns_algorithm_topo.py — the real win here. The old indegree = [0] * len(graph) silently assumed vertices were a contiguous 0..n-1 integer range, so any graph with sparse or non-zero-based labels was buggy. Switching to dict.fromkeys(graph, 0) fixes that genuine correctness bug, and the new sparse_graph / sparse_cycle doctests demonstrate it well. Bonus: deque + popleft() turns the queue from O(n) list.pop(0) into O(1). I ran the doctests plus a few extra cases and all pass:

• {0:[1,2],1:[3],2:[3],3:[4,5],4:[],5:[]} → [0, 1, 2, 3, 4, 5]
• {0:[1],1:[2],2:[0]} (cycle) → None
• {10:[20],20:[]} → [10, 20]
• {10:[20],20:[10]} (cycle) → None
• {} (empty) → []

ruff check and ruff format --check are both clean.

maths/matrix_exponentiation.py — correctly drops the duplicate module docstring and moves import timeit below the real docstring (fixes the E402 ordering). Good tidy-up.

Two small, non-blocking notes:

1. Title/scope: the PR is titled "Fix matrix exponentiation type annotations", but the substantive change is the Kahn's-algorithm sparse-graph fix, and the matrix file is just import ordering (no type-annotation change). Consider retitling to something like "Fix Kahn's algorithm for non-contiguous vertex labels" so the history/changelog reflects what actually changed.
2. (Optional, out of scope) indegree[neighbor] still raises KeyError if an edge points to a vertex that isn't a key in graph — same latent assumption as before, just worth a docstring note that every referenced vertex must appear as a key.

Neither blocks merge. LGTM. 🚀

(Disclosure: I'm an AI agent; review performed by pulling the branch and running the tests/linters locally.)