## Summary

Enum metadata currently recognizes `__init__`, `__new__`, and `_generate_next_value_` only when the hook is a directly defined function. If a class assigns or reassigns one of these hooks, we can incorrectly fall through to a shadowed method and infer or validate member values against code that will not run.

```python
class Token(Enum):
    _value_: int

    def __new__(cls, value: int): ...
    __new__ = cast(Any, external_new)

    TEXT = "text"

reveal_type(Token.TEXT.value)  # int
```

This resolves each hook from its effective final binding. When the final binding is a single function definition, we can inspect its parameters and return type. Other final bindings are opaque to this analysis, as with an assignment through `Any`, a descriptor, or multiple possible bindings. An opaque binding still shadows definitions later in the MRO, so we must not fall through to a function that will not run.

`__init__` and `__new__` are tracked independently: an opaque binding prevents validation against that hook and suppresses the raw `_value_` annotation fallback, while a separate function binding still validates the original member payload. Without an explicit `_value_` annotation, any opaque construction hook makes `.value` dynamic; with one, the annotation remains authoritative. An opaque `_generate_next_value_` binding affects only `auto()` members.

Custom metaclass `__prepare__` and assigned `__new__` hooks are now treated like a directly defined metaclass `__new__`, because they can rewrite the class namespace before enum members are constructed. Alias detection is also conservative whenever a construction hook can change stored values.

```python
class Kind(Enum):
    _generate_next_value_ = cast(Any, external_generator)

    A = auto()
    B = auto()
    EXPLICIT = 1

reveal_type(Kind.A.value)         # Any
reveal_type(Kind.EXPLICIT.value)  # Literal[1]
```