EvalBuilder can retain stale attachments across prompt/case reconfiguration

[MaestroError]

Summary

EvalBuilder can retain previously configured attachments even after a later reconfiguration appears to replace them.

Why this matters

This can make evals behave unpredictably when a builder instance is reused through helpers or shared setup. A later prompt or case may unintentionally send stale files from an earlier configuration.

Evidence

• src/EvalBuilder.php:96-98 only replaces attachments inside prompt() when the incoming attachments array is non-empty.
• src/EvalBuilder.php:111-113 only copies attachments from withCase() when the case has attachments.
• src/EvalBuilder.php:133-136 sets attachments directly, so once attachments are set there is currently no obvious clearing path through prompt(..., attachments: []) or withCase($caseWithoutAttachments).

Repro shape

A reused builder like this can keep old files attached:

evaluate(MyAgent::class)
    ->attachments([$oldFile])
    ->prompt('first prompt')
    ->run();

// Later reuse / reconfiguration
$builder
    ->prompt('second prompt', attachments: [])
    ->run();

The second run can still include $oldFile.

Suggested fix

This is only a suggestion; the actual fix should be planned carefully.

Possible directions:

• Make prompt(..., attachments: []) explicitly replace attachments with an empty array.
• Make withCase() fully replace builder attachments, including replacing them with [] when the case has none.
• Add focused tests covering attachment clearing and builder reuse semantics.

Notes

This is primarily a developer-experience and correctness issue because the current behavior is surprising and hard to notice until eval inputs drift.

[MaestroError]

Implementation plan based on the current 4.x codebase:

1. Reproduce the stale-state bug with focused builder tests.
   Add coverage in tests/EvalBuilderTest.php for builder reuse cases where attachments were previously set and a later reconfiguration is intended to clear them:

• ->attachments([...])->prompt('...', attachments: [])->run() should send an empty attachments array.
• ->attachments([...])->withCase(EvalCase::make()->prompt('...'))->run() should also send an empty attachments array.
• Keep at least one existing non-empty replacement case so we confirm we still replace attachments correctly when new attachments are provided.

2. Make prompt() treat the provided attachments argument as the full replacement value.
   In src/EvalBuilder.php, replace the guarded assignment in prompt() with an unconditional assignment. Today prompt(..., attachments: []) is interpreted as “do not change attachments”, which leaves prior state behind. The fix should make [] mean “clear attachments”.

3. Make withCase() fully replace attachment state from the case.
   In src/EvalBuilder.php, replace the guarded assignment in withCase() with direct assignment from $case->attachments. That keeps withCase() consistent with EvalCase being the source of truth for prompt, expected value, and attachments.

4. Verify no other builder API needs special handling.
   attachments() already replaces state directly, so no API expansion is needed. This should stay a small behavior fix rather than a refactor.

5. Run the targeted verification first.
   Run the relevant unit tests for EvalBuilder and then broaden only if those changes expose related failures.

Why this plan fits the current code:

• src/EvalBuilder.php:96-98 only replaces prompt attachments when the new array is non-empty.
• src/EvalBuilder.php:111-113 does the same for withCase().
• src/EvalBuilder.php:133-136 already uses direct replacement in attachments(), so making prompt() and withCase() behave the same is the minimal consistent fix.

Issue classification: this looks like a bug, not an enhancement, because the current behavior preserves stale inputs that the later configuration appears to replace.