TYP: broadcast_to shape-typing - #32247

TLDR; broadcast_to used to ignore all shape types, now it propagates it whenever shape is a tuple.

The stubs for np.broadcast_to completely ignored the shape type, even though there are many common usecases where it (viz. the shape-type) can be exactly statically known.

This propages the shape-types in case it's assignable to tuple[int, ..] (so e.g. shape=[1, 2] wouldn't work, because type-checkers aren't able to statically determine the size of a list like they can for tuples -- lists are mutable and homogeneous, whereas tuples are immutable an heterogeneous).

There's one annoying thing here though: some typecheckers such as pyright propagate the Literal intergers "inside" the tuple shape-type, but others (like mypy) don't. So broadcast_to(a, (1, 2)) will have a shape-type of tuple[int, int] according to mypy, whereas pyright will infer it as tuple[Literal[1], Literal[2]]. I could've worked around this (using finite constrained type variables), but that would've harmed generality. These int vs Literal[] difference also won't matter in the real word, because both are assignable to int, and broadcast_to only accepts positive integers (unlike e.g. reshape, which accepts negative integers, which in this case could have lead to nonsensical shape-types in case of e.g. shape=(2, -1)). So nothing to worry about, just something worth noting.

Fully written by me, pre-reviewed and audited by AI (see this rank-typing tracker hist for details).