fix(generator): emit lint-clean GAPIC output

[bshaffer]

Fixes #9432. Unblocks the prefer-const / no-floating-promises half of the .eslintrc.json override added in #9429.

Four template fixes (cjs + esm), plus regenerated baselines:

Rule	Fix
promise/always-return	return; in the client close() then-callback
promise/always-return	return; in both generated close() tests
no-floating-promises	chain .catch(err => {throw err}) on the Locations mixin callback test — its IAM and operations siblings already do this
prefer-const	let routingParameter → const (only ever Object.assign-ed)

Verification. Baselines are ESLint-ignored, so CI can't check this. I applied exactly these transformations to the real files that failed in #9427 and linted them with the four rules live:

gapic_data_chat_service_v1.ts     285,301 always-return + 1775 floating  ->  0 errors
data_chat_service_client.ts       1807 always-return                     ->  0 errors
sql_instances_service_client.ts   2212 prefer-const + 7082 always-return ->  0 errors

Generator suite: 188 passing. Baseline diff is 240 files / 0 deletions, containing only + return; (350), let→const (12), and the 2 mixin .catch sites.

Not sufficient on its own — librarian.yaml pins the generator by tag + tarball checksum, so this needs a new gapic-generator-v* tag and a librarian.yaml bump before the override lines can be dropped.

[gemini-code-assist]

Code Review

This pull request updates the TypeScript GAPIC generator templates for both CommonJS (CJS) and ECMAScript Modules (ESM), subsequently regenerating a large number of baseline files. The modifications include changing routingParameter from let to const, adding explicit return statements inside client close callbacks and test assertions, and appending .catch handlers to client calls within test promises. The reviewer identified a critical issue in both the CJS and ESM test templates: throwing an error asynchronously inside a .catch block within a new Promise executor does not reject the outer promise, causing it to hang indefinitely. To resolve this, the reviewer recommends replacing .catch(err => {throw err}) with .catch(reject) to properly propagate errors.

[bshaffer]

@gemini-code-assist please review!

[gemini-code-assist]

Code Review

This pull request updates the TypeScript GAPIC generator templates (both CJS and ESM) and regenerates the corresponding baseline files. The modifications include adding explicit return; statements inside callbacks, changing let routingParameter to const, and refactoring promise rejections to use .catch(reject). The feedback highlights an issue in the test templates where throwing an error inside a .catch() block in callback-based tests (using done) can cause timeouts; chaining .catch(done) is recommended to ensure tests fail cleanly and immediately.

[gemini-code-assist]

In callback-based tests (using done), throwing an error inside a .catch() block can cause the test to timeout rather than failing immediately with the actual error. Chaining .catch(done) instead ensures that any rejection is passed directly to the callback, failing the test cleanly and immediately.

            client.{{ id.get(\"close\") }}().then(() => {\n                done();\n                return;\n            }).catch(done);

[gemini-code-assist]

In callback-based tests (using done), throwing an error inside a .catch() block can cause the test to timeout rather than failing immediately with the actual error. Chaining .catch(done) instead ensures that any rejection is passed directly to the callback, failing the test cleanly and immediately.

            client.{{ id.get(\"close\") }}().then(() => {\n                done();\n                return;\n            }).catch(done);

[gemini-code-assist]

In callback-based tests (using done), throwing an error inside a .catch() block can cause the test to timeout rather than failing immediately with the actual error. Chaining .catch(done) instead ensures that any rejection is passed directly to the callback, failing the test cleanly and immediately.

            client.{{ id.get(\"close\") }}().then(() => {\n                done();\n                return;\n            }).catch(done);

[gemini-code-assist]

In callback-based tests (using done), throwing an error inside a .catch() block can cause the test to timeout rather than failing immediately with the actual error. Chaining .catch(done) instead ensures that any rejection is passed directly to the callback, failing the test cleanly and immediately.

            client.{{ id.get(\"close\") }}().then(() => {\n                done();\n                return;\n            }).catch(done);