Fix invalid prototype slot node issue

[weixq709]

Describe what this PR does / why we need it

When a singleton ProcessorSlot is placed before a prototype (non-singleton)
ProcessorSlot in DefaultProcessorSlotChain, all chains share the same singleton
instance. Each time a new chain is built, addLast calls setNext directly on
the shared singleton, overwriting its next pointer. This causes previously built
chains to lose their own prototype slot node — making the prototype slot invalid.

This PR introduces PrototypeSlotWrapper and modifies DefaultProcessorSlotChain#addLast
to wrap every slot in a new PrototypeSlotWrapper per chain. Each wrapper owns an
independent next pointer (inherited from AbstractLinkedProcessorSlot), so the
singleton's next field is never modified during chain construction, and each chain
maintains its own correct node linkage.

Does this pull request fix one issue?

Fixes #3007

Describe how you did it

• Added PrototypeSlotWrapper (slots/block/flow/PrototypeSlotWrapper.java):
  a thin wrapper extending AbstractLinkedProcessorSlot that delegates entry,
  exit, fireEntry, and fireExit to the underlying slot, while keeping its
  own chain-local next pointer via the inherited field.

• Modified DefaultProcessorSlotChain#addLast
  (slotchain/DefaultProcessorSlotChain.java):
  wrap the incoming slot in a PrototypeSlotWrapper before appending it to the
  chain, so end.setNext and end = processor always operate on a fresh wrapper
  instance rather than the slot itself.

Describe how to verify it

Two test cases added in ProcessorSlotChainTest (slots/ProcessorSlotChainTest.java):

• testBeforeFix_nextOfSingletonIsShared: uses a Mockito spy to simulate the old
  addLast logic (no wrapper) and asserts that after building two chains, both
  chains' prototype slot node is the same object — confirming the bug.

• testAfterFix_eachChainHasItsOwnWrapper: uses the fixed DefaultProcessorSlotChain
  and asserts that the two chains hold different PrototypeSlotWrapper instances as
  their second node — confirming the fix.

Special notes for reviews

PrototypeSlotWrapper does not override getNext / setNext, so the chain-local
next field on the wrapper is used for node linkage. fireEntry and fireExit are
delegated to the underlying slot to preserve the original propagation behavior.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

joyce seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}