[Feature Request]: Replace `any` types in core/types/ with typed models — automation.ts and tool.ts

[web-dev0521]

Feature Description

core/types/automation.ts and core/types/tool.ts contain 18 untyped any instances that directly affect the AI automate feature. The critical violations:

automation.ts (frontend/src/core/types/automation.ts):

• parameters: Record<string, any> — appears in 2 places in the automation step/operation types
• icon: any — MUI Icon component type (line 68)

tool.ts (frontend/src/core/types/tool.ts):

• ToolOperationHook<any> (line 30) — hook return type is fully untyped
• getDefaultParameters: () => any (line 36)
• metadata?: Record<string, any> (line 64)

These types are actively imported by 15+ files including AutomationSelection.tsx, AutomationRun.tsx, AutomationCreation.tsx, and the automation hooks. Every file consuming these types loses IDE autocomplete, refactoring safety, and compile-time error detection on parameter shapes.

Why is this feature valuable?

Active impact on the automate feature: The automation pipeline is under active development. parameters: Record<string, any> means automation step parameters have no validated shape — incorrect parameter names or types fail silently at runtime instead of at compile time.

Discriminated union is feasible: Operation names are known constants (the full operation list is defined in tool_models.py and mirrored in the frontend tool registry). A discriminated union keyed on operation name can give each operation its own typed parameter schema, exactly matching what the backend expects.

Precedent exists: PRs #6033 (desktop/) and #5949 (proprietary/) already completed any elimination in those layers. core/types/ is the logical next target in this campaign.

CLAUDE.md alignment: The project's own frontend guidelines require typed parameters — Record<string, any> across automation boundaries directly contradicts this.

Suggested Implementation

1. automation.ts: Replace parameters: Record<string, any> with a discriminated union — one typed parameters interface per tool operation, keyed on the operation's endpoint string. Example:

   type AutomationStepParameters =
     | { operation: "/api/v1/misc/compress-pdf"; parameters: CompressPdfParams }
     | { operation: "/api/v1/general/merge-pdfs"; parameters: MergePdfParams }
     | ...

2. tool.ts: Replace ToolOperationHook with a concrete generic constraint tied to the tool's parameter type. Replace getDefaultParameters: () => any with the actual return type.
3. icon: any is a known MUI component typing limitation — acceptable to leave or wrap with React.ElementType.

Additional Information

• 18 total any instances confirmed across frontend/src/core/types/ via static analysis
• Affected consumer files: AutomationSelection.tsx, AutomationRun.tsx, AutomationCreation.tsx, and 12+ additional hooks and services
• Related prior work: Fix any type usage in desktop/ #6033 (desktop/ any cleanup), Fix any type usage in proprietary/ #5949 (proprietary/ any cleanup)
• Tool parameter schemas are already typed in frontend/src/core/data/ — the union types can be derived from existing definitions without duplicating schemas

No Duplicate of the Feature

• I have verified that there are no existing features requests similar to my request.