#16284: fix(feishu): route tool credentials by account parameter

## Summary This PR fixes multi-account credential isolation for the official Feishu extension by allowing callers to explicitly select which Feishu account to use per tool invocation. ## Problem In multi-account setups, Feishu tools previously resolved a single client at registration time (effectively locking to the first enabled account). This caused cross-account operations and permission issues. ## Solution - Add optional `account?: string` to all Feishu tool schemas (doc/wiki/drive/perm/bitable) - Introduce `resolveToolClient(cfg, accountId?)` to resolve the Feishu client at execution time: - If `account` is provided: use that configured + enabled account - If omitted: fall back to the first enabled account (preserves prior behavior) - Update tool handlers to use `resolveToolClient()` instead of a closure-captured client - Migrate bitable tool registration away from legacy direct config access to the standard `listEnabledFeishuAccounts()` pattern Replaces #15241 (closed due to deleted fork). ## Reviewer notes - Additive & backward-compatible: omitting `account` keeps existing behavior - Clear error messages for unconfigured / disabled `account` IDs - Changes are scoped to `extensions/feishu/**` only ## Test plan - [x] CI is green - [x] New `extensions/feishu/src/tools-account.test.ts` covers: explicit account routing, fallback behavior, unconfigured/disabled errors, schema validation _Reviewer focus: schema additions + account resolution logic in `resolveToolClient()`._ ## Greptile Overview ### Greptile Summary Added optional account parameter to all Feishu tool schemas (doc, wiki, drive, perm, bitable) to enable multi-account credential routing. Introduced shared resolveToolClient() helper in accounts.ts that resolves the correct client from the named account with clear error handling. When the account parameter is omitted, tools fall back to using the first enabled account, preserving backward compatibility. ### Key changes: - New resolveToolClient() function in accounts.ts:152 centralizes account resolution logic with proper error messages for unconfigured/disabled accounts - All tool schemas updated with consistent AccountField definition (optional string parameter) - Bitable tools migrated from legacy direct config access to standard listEnabledFeishuAccounts() pattern - Comprehensive test coverage in tools-account.test.ts validates explicit account resolution, fallback behavior, and error cases ## Confidence Score: 5/5 - This PR is safe to merge with minimal risk - The implementation is well-structured with proper error handling, comprehensive test coverage (130 lines of tests covering all critical paths), and maintains backward compatibility. The resolveToolClient() helper provides clear error messages for edge cases. All changes follow consistent patterns across tool files. The only minor concern is the inclusion of unrelated web-fetch commits, but these are also well-tested and don't affect the core Feishu functionality. - No files require special attention <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds optional `account` parameter to all Feishu tool schemas (doc, wiki, drive, perm, bitable) and introduces a shared `resolveToolClient()` helper in `accounts.ts` to route tool invocations to the correct Feishu account at execution time. When `account` is omitted, the tool falls back to the invoking bot's account (via `ctx.agentAccountId`) then to the first enabled account, preserving backward compatibility. Bitable tools are also migrated from legacy direct config access to the standard `listEnabledFeishuAccounts()` registration pattern. - New `resolveToolClient()` centralizes account resolution with clear error messages for unconfigured/disabled accounts - All tool registrations migrated from static `getClient()` closures to dynamic per-invocation resolution via the `(ctx) => { ... }` factory pattern - `mediaMaxBytes` in `docx.ts` now resolves from the per-invocation account config rather than being fixed to the first account at registration time - Comprehensive tests cover explicit account routing, preferred account fallback, error cases, and schema validation <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with minimal risk; the changes are additive, backward-compatible, and well-tested. - The implementation is well-structured with proper error handling, comprehensive test coverage, and maintains backward compatibility. The `resolveToolClient()` helper provides clear error messages for edge cases and all tool files follow a consistent pattern. One minor style concern around repeated `AccountField` definitions is non-blocking. No logical errors found. - No files require special attention _{Last reviewed commit: e2cb790} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->