feat(auth): add customMethodPickerTermsContent slot to FirebaseAuthScreen

[demolaf]

Closes #1338

Adds a customMethodPickerTermsContent slot to FirebaseAuthScreen (and termsContent to AuthMethodPicker) so developers can replace the default "By continuing..." footer with their own UI — e.g. an explicit acceptance checkbox required by some jurisdictions (GDPR, French law).

Usage

On FirebaseAuthScreen composable:

customMethodPickerTermsConfiguration = MethodPickerTermsConfiguration(
    content = {
        Row(
            modifier = Modifier.padding(horizontal = 16.dp, vertical = 8.dp),
            verticalAlignment = Alignment.CenterVertically
        ) {
            Checkbox(
                checked = termsAccepted,
                onCheckedChange = { termsAccepted = it }
            )
            Text(
                text = "I have read and accept the Terms of Service and Privacy Policy",
                style = MaterialTheme.typography.bodySmall,
                modifier = Modifier.padding(start = 8.dp)
            )
        }
    },
    accepted = termsAccepted,
    disableProvidersUntilAccepted = true,
),

Preview

untitled.webm

[gemini-code-assist]

Code Review

This pull request introduces the ability to customize the Terms of Service and Privacy Policy footer in the authentication method picker by adding a customMethodPickerTermsContent parameter to FirebaseAuthScreen and AuthMethodPicker. However, the current implementation introduces a breaking change where the default ToS footer is hidden when a customLayout is provided without a custom terms composable. Additionally, there is a functional gap where the state of a custom terms checkbox cannot be used to gate or disable the default sign-in buttons, which is critical for compliance. Finally, the unit tests should be updated to reflect the corrected behavior once these issues are addressed.

[just1and0]

When disableProvidersUntilAccepted is true, this only disables the default provider buttons. Custom layouts still receive the raw onProviderSelected callback, so they can start auth before terms are accepted. Since this is meant to enforce explicit consent, should we wrap the callback and pass the gated version to both the default layout and custom layouts or is this expected behaviour ?

[demolaf]

When disableProvidersUntilAccepted is true, this only disables the default provider buttons. Custom layouts still receive the raw onProviderSelected callback, so they can start auth before terms are accepted. Since this is meant to enforce explicit consent, should we wrap the callback and pass the gated version to both the default layout and custom layouts or is this expected behaviour ?

If the user has chosen to provide their own layout then they would be responsible for handling the behaviour of onProviderSelected, if we gate this then this takes away control from the user.

This is the intended behaviour.