build(client): add inline disables for upcoming lint rules

[tylerbutler]

Summary

Adds inline eslint-disable-next-line comments across ~79 files to prepare for upcoming stricter lint rules in typescript-eslint. These suppressions prevent behavioral changes from automatic code transformations.

The suppressed rules are:

• @typescript-eslint/prefer-nullish-coalescing - Using ?? instead of || could change behavior for falsy values like 0, "", or false
• @typescript-eslint/prefer-optional-chain - Using ?. instead of && could change behavior in some edge cases
• @typescript-eslint/strict-boolean-expressions - Intentional truthy/falsy checks
• @typescript-eslint/no-unsafe-enum-comparison - Intentional enum comparisons
• @typescript-eslint/await-thenable - Known patterns where await is used intentionally
• @typescript-eslint/no-base-to-string - Known cases where toString behavior is expected

Two files (directory.ts, client.rollback.spec.ts) use file-wide disables with TODO comments to track fixing the violations later.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[jason-ha]

@tylerbutler, @anthony-murphy, @Abe27342, @Josmithr, @noencke,
Does anyone know where the follow-up work items are from this?
I saw a suppression in presence that has an incorrect comment but sounds authoritative. I wouldn't expect people to go fix the comment or the defect.
Then I peeked to see if this might be broad issue. I found "TODO:" comments without a work item and I didn't find work items in ADO with related defect string. So it feels like we are just dropping follow-up.

Looking at ??= suppressions specifically there are comments that say don't fix because it might be falsy. But ?? does not care about falsy, right? It only checks for null or undefined and I am guessing is very appropriate in a lot of the places that were suppressed.