Auth-only constructor to avoid root package dependency closure

## Summary

Applications that only use Firebase Auth must currently import the root `firebase.google.com/go/v4` package to construct an `*auth.Client`:

```go
app, err := firebase.NewApp(ctx, config, opts...)
client, err := app.Auth(ctx)
```

Because the root package imports the SDK's other service packages, this pulls Firestore, Storage, Realtime Database, Messaging, Remote Config, App Check, and their transitive Google Cloud dependencies into the Go compile graph.

Would the project accept a non-breaking, auth-only constructor or ID-token verifier in `firebase.google.com/go/v4/auth` that reuses the existing verifier implementation without importing the root Firebase package?

## Use case

Our service only calls `VerifyIDToken`. It does not use Firestore, Storage, Realtime Database, Messaging, Remote Config, or App Check.

The public `auth.NewClient` cannot currently be used by an external module because it requires `*internal.AuthConfig`. Go's `internal` import rules prevent applications from constructing that configuration, and its documentation directs applications back through `firebase.App`.

This appears to be the same underlying concern raised in:

- #187
- #279

Those issues predate the current module structure and modern cold-build/build-cache costs.

## Measurements

We measured a stripped Linux production binary using Firebase Admin Go `v4.19.0`.

As an upper-bound experiment only, we temporarily replaced root `firebase.NewApp(...).Auth(...)` initialization with a stub, while retaining the narrower `firebase.google.com/go/v4/auth` package for the existing token types. The stub was not a functional change and was immediately reverted.

```text
Stripped binary: 124,186,889 B -> 108,671,241 B
Production dependencies: 1,254 -> 1,055
```

That is approximately 15.5 MB and 199 dependencies behind the root initialization closure in this service. Some of that closure may be eliminated by the linker in other applications, but every imported package still affects compilation and build-cache storage.

## Possible API

A narrow client constructor:

```go
client, err := auth.NewClient(ctx, auth.Config{
ProjectID: projectID,
}, opts...)
```

Or, if exposing the complete Auth client this way is undesirable, a verifier-specific API:

```go
verifier, err := auth.NewIDTokenVerifier(ctx, projectID, opts...)
token, err := verifier.VerifyIDToken(ctx, idToken)
```

The new API could reuse the current internal verifier so behavior remains identical, including:

- RS256 signature validation
- Firebase certificate fetching and cache semantics
- project ID audience validation
- `https://securetoken.google.com/` issuer validation
- `kid`, subject, issued-at, and expiry checks
- clock-skew handling
- `*auth.Token` output
- Auth Emulator behavior, where applicable

This would be additive and would not change the existing `firebase.App` API.

If the maintainers agree with the API direction, we would be interested in contributing an implementation and tests upstream.