Let's Plan a Technical Debt Cleanup: Addressing Disabled TypeScript ESLint Rules

[BettaiebMohamed]

I noticed in eslint.config.js that several critical TypeScript safety rules are currently disabled (lines 109-113):
'@typescript-eslint/no-unsafe-argument': 'off',
'@typescript-eslint/no-unsafe-assignment': 'off',
'@typescript-eslint/no-unsafe-call': 'off',
'@typescript-eslint/no-unsafe-member-access': 'off',
'@typescript-eslint/no-unsafe-return': 'off',
These rules are disabled "once the codebase is cleaned up" - but when should we plan this cleanup?

Timeline: Should we target the next major version (12.0) or incremental cleanup?
Approach: Big-bang fix vs. gradual re-enablement with issue tracking?
Priority: Which rules should we tackle first based on risk/impact?
Resources: Who can help lead this effort and what's the estimated workload?
Impact: Currently, the codebase lacks type safety enforcement, which could lead to runtime errors and makes refactoring riskier.

Has anyone started working on this already?
Are there specific areas of the codebase that need more attention?
Should we create a tracking issue or epic for this cleanup effort?