Make FunctionException a sealed class for v3

[spydon]

In #1545 the FunctionsFetchException, FunctionsRelayException, and FunctionsHttpException subtypes were added under FunctionException in a non-breaking way (plain inheritance), so existing catch (FunctionException) blocks keep working.

For v3 we should make FunctionException a sealed class so consumers get a compile-checked exhaustive switch over the failure mode:

try {
  await supabase.functions.invoke('hello');
} on FunctionException catch (error) {
  final message = switch (error) {
    FunctionsFetchException() => 'Network failure',
    FunctionsRelayException() => 'Relay error',
    FunctionsHttpException()  => 'Function returned ${error.status}',
  };
}

Why this is breaking (hence v3)

sealed implies abstract, so:

• The public const FunctionException(...) constructor can no longer be used by external code to instantiate a bare FunctionException (e.g. in tests/mocks).
• External packages can no longer extend or implement it.

A non-breaking intermediate sealed base does not help: as long as a bare FunctionException remains constructable, any switch must allow for one, so the three subtypes can never form the closed set the compiler checks for exhaustiveness. Real three-way exhaustiveness requires FunctionException itself to be sealed.

Where

• packages/functions_client/lib/src/types.dart

[hiSandog]

Sealing the hierarchy gives useful exhaustiveness, but the v3 migration should provide a replacement for tests that currently instantiate or subclass FunctionException. Public const constructors for each concrete subtype, with stable fields for cause/status/response, would let mocks create realistic failures without reopening the hierarchy. A compile test for the exhaustive switch plus serialization/string-output compatibility would make the breaking change predictable across the functions client and downstream packages.

[spydon]

@hiSandog I don't see what the point would be to subclass or instantiate FunctionException.
The only thing a mock would no longer be able to do is to construct a bare, typeless FunctionException. But that's an anti-pattern the seal is deliberately encouraging you away from: if you're testing error handling, you want a specific failure mode, not an abstract stand-in.