[konlue]

Describe what this PR does / why we need it

Locks the acceptance behavior of #269 with the test suite the issue requires. With #333 merged, the main scenario is already covered: an interceptor that swaps the whole registry via ModelRequest.toolRegistry(...) now has its registry flow into the effective tool set and back to the same-turn execution, so the issue's repro (original=1, replacement=0) no longer reproduces on current main — but none of the six behavior scenarios the issue's acceptance criteria ask for existed as tests, and the fallback/multi-attempt binding semantics were unproven.

Does this pull request fix one issue?

Fixes #269

Describe how you did it

Five new offline cases in ReActAgentTest (existing ScriptedClient pattern, one with a scripted-stream subclass):

1. Issue repro: an interceptor swaps the registry for a same-named implementation B — execution counts prove B ran (1) and the pre-chain A never did (0).
2. A tool added by the interceptor (absent from the static registry) is disclosed and executable.
3. A tool removed by the interceptor never falls back to the pre-chain binding — the call surfaces through the existing unknown-tool error path.
4. Each turn executes with that turn's own bindings: a tool disclosed only on the first model call executes once and is gone on the second turn even though the shared message list keeps growing.
5. The streaming tool-call path executes the replacement binding identically.

No production code was needed: the effective-set handoff introduced in #333 (chain-end resolution, per-turn AtomicReference, success-turn ownership) already satisfies the issue's acceptance criteria; this PR turns that into locked, reviewable behavior.

Describe how to verify it

./mvnw -pl argi-agent/argi-agent-core -am test -DskipTests=false -Dtest=ReActAgentTest — 21/21 green (16 pre-existing + 5 new). Full argi-agent-core reactor: 132/132. Checkstyle clean.

Special notes for reviews

The issue's duplicate-name clause (static shadows dynamic on conflicts) was already settled by #333's resolveTools/effectiveToolSet merge and is exercised by staticToolShadowsDynamicToolOnNameConflict. If the maintainers would rather close #269 as covered-by-#333 without this test PR, I'm happy to — but the acceptance criteria explicitly call for these behavior tests, so submitting them as the issue's deliverable.