ESLint 9 Migration

The Pull Request [chore(deps): update dependency gts to v7 #3856](https://github.com/googleapis/google-api-nodejs-client/pull/3856) is currently blocked due to CI failures.

The core of the issue is that `gts` v7 upgrades the linter to **ESLint v9**, which introduces a breaking change by switching to a new "Flat Config" system. The existing configuration infrastructure is incompatible with this new version.

Resolving this requires a two-step approach.

---

## Step 1: Infrastructure Migration (ESLint 9 Flat Config)
ESLint 9 drops support for `.eslintrc.json` and `.eslintignore`. The project must migrate to `eslint.config.js` and `eslint.ignores.js`.

### Findings & Reference
In Flat Config, ignore patterns are strictly relative to the configuration file, and global variables (like `process` or `module` in Node.js) must be explicitly declared in the config for JavaScript files.

- **Reference:** [ESLint Migration Guide - Ignoring Files](https://eslint.org/docs/latest/use/configure/migration-guide#ignoring-files)

### Required Technical Changes
1. **Create `eslint.ignores.js`**: Export the array of ignore patterns (migrated from `.eslintignore`).
2. **Create `eslint.config.js`**:
- Extend `gts`.
- Import ignore patterns.
- Declare `globals.node` for `**/*.js` files to prevent `no-undef` errors.
3. **Clean up**: Delete `.eslintrc.json` and `.eslintignore`.

---

## Step 2: Code Compliance (New Linting Findings)
After migrating to **ESLint v9**, the new linter identifies several violations in the existing codebase that were previously ignored or not checked with the same intensity. We need to determine the best path forward for these findings, whether is to mute the findings, fix the findings, or come up with a hybrid approach.

### Findings
The following rules are failing across multiple files (many of which are autogenerated):
- `@typescript-eslint/no-unused-vars`
- `@typescript-eslint/no-explicit-any`
- `@typescript-eslint/no-unused-expressions`

### Open Questions:

1. **Mute the findings (Short-term):** Should we disable these rules in `eslint.config.js` to unblock the `gts` v7 upgrade? This would maintain the current state of the codebase while adopting the new tooling.
2. **Fix the findings (Long-term):** Since many of these files are autogenerated, should we block the upgrade until the generator logic is updated to produce compliant code?
3. **Hybrid Approach:** Mute them now but create a follow-up task to address the generator's output?

> NOTE: muting these rules in the new `eslint.config.js` allowed all linting checks and tests to pass successfully when testing this changes locally.