Implement multi-action step caching

[panda-sandeep]

Currently only single-action steps are cached (see src/index.ts cache logic). Steps that require multiple tool calls (e.g., file upload = click + setInputFiles) are always re-executed via AI. Design and implement a caching strategy for multi-action sequences.

This requires: defining a serialization format for action sequences, handling partial failures (some actions succeed, later ones fail), and cache invalidation when the sequence changes. Reference the existing caching in src/index.ts and src/data-cache.ts.

[ritikpal1122]

Hey @panda-sandeep — keen to take this on. Wanted to confirm the direction before I start.

Quick read of where we are: single-action cache writes a flat hash at step:${userFlow}:${step.description} (index.ts:449) and replays via a switch over 6 actions (index.ts:283). Multi-action is gated out at index.ts:446 on allToolCalls.length === 1,
so click + setInputFiles etc. always re-hit the AI.

What I'd change:

• Cache value goes from a flat hash to a JSON array with a version field. Old entries miss cleanly on read and get overwritten — no migration.
• pendingCacheData in tools.ts:681 currently overwrites on every tool call; push into an array instead, flush on step success.
• On replay, run each action in order and reuse verifyActionEffect between them (already there at index.ts:335). Any mismatch → bail and fall back to AI for the whole step. No partial replay, cache stays best-effort.
• Allowlist stays tight: only cache when every tool call is replayable (the existing 6 + file upload). Anything exotic, skip.

Two things to confirm:

1. Reuse the same redis key with a version field, or fresh prefix like step:v2:...? I'd reuse.
2. For file upload, keep the path literal in cache, or require step.data.value on replay like we do for fill?

If direction's fine I'll open a draft PR. Tests: click+fill hit, file upload hit, mid-sequence verify fail → AI fallback, version miss.

[ritikpal1122]

@panda-sandeep can you please check this ?