fix: initialize auth in requirePermissions before projectId check

[joehan]

Description

Fixes an issue where running commands with Application Default Credentials (ADC) without a selected/configured project causes a confusing Unable to refresh auth: not yet authenticated error.

When a command that performs client-side IAM checks via requirePermissions is run without an active project, requirePermissions returned early before calling requireAuth. This left the local auth state (e.g. lastOptions and accessToken) uninitialized. When the command's action then proceeded to make API calls (which fallback to the active auth token), the auth client encountered an uninitialized auth state, resulting in a rejected promise with the Unable to refresh auth message.

This PR fixes it by calling requireAuth(options) at the beginning of requirePermissions, ensuring that the auth client and local tokens are always initialized before any early return.

Fixes #10879

Scenarios Tested

1. Tested running firestore:locations under ADC without an active project (expected behavior: proper GCP API/project error instead of auth failure).
2. Tested running firestore:locations under ADC with a valid project (expected behavior: lists locations successfully).
3. Ran full Mocha test suite (npm run mocha:fast) to ensure no regressions in auth hooks.

Sample Commands

• Running without a project (before fix vs after fix):
  firebase firestore:locations --debug

  • Before Fix:

    Error: Unable to refresh auth: not yet authenticated.
    

  • After Fix:

    Error: Request to https://firestore.googleapis.com/v1/projects/null/locations had HTTP Error: 403, Permission denied on resource project null.
    

• Running with a project under ADC:
  firebase firestore:locations --project adam-test-c4a4d --debug

  • Before / After Fix:
    Lists locations successfully.

[gemini-code-assist]

Code Review

This pull request modifies src/requirePermissions.ts to call requireAuth(options) at the very beginning of the requirePermissions function, before retrieving and checking the project ID. There are no review comments, and I have no feedback to provide.

[aalej]

LGTM! Although, just to note, we do call requireAuth before requirePermissions in most commands which would explain why we never really encountered this issue on other commands. For example functions:secrets:get -

firebase-tools/src/commands/functions-secrets-get.ts

Lines 7 to 12 in af93f9e

	export const command = new Command("functions:secrets:get <KEY>")
	.description("get metadata for secret and its versions")
	.before(requireAuth)
	.before(secretManager.ensureApi)
	.before(requirePermissions, ["secretmanager.secrets.get"])
	.action(secrets.describeSecret);

we don't do this pattern on firestore:locations

firebase-tools/src/commands/firestore-locations.ts

Lines 10 to 14 in af93f9e

	export const command = new Command("firestore:locations")
	.description("list possible locations for your Cloud Firestore database")
	.before(requirePermissions, ["datastore.locations.list"])
	.before(warnEmulatorNotSupported, Emulators.FIRESTORE)
	.action(async (options: FirestoreOptions) => {

Since we moved requireAuth on the very top of requirePermissions, we might be able to remove the before(requireAuth) on other commands

note: an alternative fix might be to follow the existing pattern and add requireAuth before requirePermissions