fix: change None only field types to Literal[None]

[vite-falcon]

This is to fix the error from Pydantic v2.12+ like the one below:

.nox/test/lib/python3.14/site-packages/supabase/__init__.py:1: in <module>
    from supabase_auth.errors import (
.nox/test/lib/python3.14/site-packages/supabase_auth/__init__.py:3: in <module>
    from ._async.gotrue_admin_api import AsyncGoTrueAdminAPI  # type: ignore # noqa: F401
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.nox/test/lib/python3.14/site-packages/supabase_auth/_async/gotrue_admin_api.py:6: in <module>
    from ..helpers import (
.nox/test/lib/python3.14/site-packages/supabase_auth/helpers.py:27: in <module>
    from .types import (
.nox/test/lib/python3.14/site-packages/supabase_auth/types.py:104: in <module>
    class AuthOtpResponse(BaseModel):
.nox/test/lib/python3.14/site-packages/pydantic/_internal/_model_construction.py:242: in __new__
    set_model_fields(cls, config_wrapper=config_wrapper, ns_resolver=ns_resolver)
.nox/test/lib/python3.14/site-packages/pydantic/_internal/_model_construction.py:566: in set_model_fields
    fields, class_vars = collect_model_fields(cls, config_wrapper, ns_resolver, typevars_map=typevars_map)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.nox/test/lib/python3.14/site-packages/pydantic/_internal/_fields.py:364: in collect_model_fields
    field_info = FieldInfo_.from_annotated_attribute(ann_type, assigned_value, _source=AnnotationSource.CLASS)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.nox/test/lib/python3.14/site-packages/pydantic/fields.py:382: in from_annotated_attribute
    raise PydanticUserError(
E   pydantic.errors.PydanticUserError: Error when building FieldInfo from annotated attribute. Make sure you don't have any field name clashing with a type annotation.
E
E   For further information visit https://errors.pydantic.dev/2.12/u/unevaluable-type-annotation

What kind of change does this PR introduce?

Bug fix that started showing after upgrading Pydantic to v2.12.0 as part of the chore to upgrade Python to 3.14

What is the current behavior?

Any imports, even if they are not related to Auth classes, fail with the error seen above. This is because the check in Pydantic looks like this:

if annotation is not MISSING and annotation is default:
    raise PydanticUserError(
        'Error when building FieldInfo from annotated attribute. '
        "Make sure you don't have any field name clashing with a type annotation.",
        code='unevaluable-type-annotation',
    )

Here, the check is that the annotation (which is None) is the same as the default value, which is also None.

What is the new behavior?

The change is to use Literal[None] as the annotation on the field, while maintaining the default as None. It then makes the check annotation is default evaluate to False.

Additional context

None

[o-santi]

I cannot reproduce this error, even after updating pydantic to 2.12.0 and python to 3.14.0-candidate-2. Additionally, the error you reported, by what is described in the pydantic reference link in the error message, is about field names and annotations having the same name, not annotations and default values. Thus, I don't think that changing None to Literal[None] would be the solution to fixing this.

Because type annotations are evaluated after assignments, you might get unexpected results when using a type annotation name that clashes with one of your fields.

class Model(BaseModel):
   date: date = Field(description='A date')

Can you explain how to reproduce this?

[o-santi]

Okay, I can reproduce this by dropping into a shell and running import supabase_auth, not sure why the tests didn't catch this though. Still, I'm not certain this is a problem on our end, as None : None is a perfectly passable type. According to the 2.12 changelog, it seems that this specific FieldInfo class underwent some heavy rewriting. I'll open an issue in their repo to confirm if this behavior is intended.

[o-santi]

I've opened issue pydantic/pydantic#12368, let's see what they say before changing this behavior ourselves. If it indeed should be a bug, then I'll quickly merge this.

[o-santi]

Indeed, this seems to be a bug with pydantic itself pydantic/pydantic#12370. I'll keep this PR open until we're sure it is resolved upstream.