[ty] Do not look up __init__ on instances (#18092)

## Summary

Dunder methods are never looked up on instances. We do this implicitly
in `try_call_dunder`, but the corresponding flag was missing in the
instance-construction code where we use `member_lookup_with_policy`
directly.

fixes https://github.com/astral-sh/ty/issues/322

## Test Plan

Added regression test.

crates/ty_python_semantic/resources/mdtest/attributes.md

@@ -1462,6 +1462,14 @@ Instance attributes also take precedence over the `__getattr__` method:
 reveal_type(c.instance_attr)  # revealed: str
 ```
 
+Importantly, `__getattr__` is only called if attributes are accessed on instances, not if they are
+accessed on the class itself:
+
+```py
+# error: [unresolved-attribute]
+CustomGetAttr.whatever
+```
+
 ### Type of the `name` parameter
 
 If the `name` parameter of the `__getattr__` method is annotated with a (union of) literal type(s),

crates/ty_python_semantic/resources/mdtest/named_tuple.md

@@ -149,3 +149,20 @@ Person = namedtuple("Person", ["id", "name", "age"], defaults=[None])
 alice = Person(1, "Alice", 42)
 bob = Person(2, "Bob")
 ```
+
+## NamedTuple with custom `__getattr__`
+
+This is a regression test for <https://github.com/astral-sh/ty/issues/322>. Make sure that the
+`__getattr__` method does not interfere with the `NamedTuple` behavior.
+
+```py
+from typing import NamedTuple
+
+class Vec2(NamedTuple):
+    x: float = 0.0
+    y: float = 0.0
+
+    def __getattr__(self, attrs: str): ...
+
+Vec2(0.0, 0.0)
+```

crates/ty_python_semantic/src/types.rs

@@ -4516,7 +4516,8 @@ impl<'db> Type<'db> {
                 .member_lookup_with_policy(
                     db,
                     "__init__".into(),
-                    MemberLookupPolicy::MRO_NO_OBJECT_FALLBACK,
+                    MemberLookupPolicy::NO_INSTANCE_FALLBACK
+                        | MemberLookupPolicy::MRO_NO_OBJECT_FALLBACK,
                 )
                 .symbol
                 .is_unbound()