[Fix][Connector-V2] Run Pulsar cleanup with connector classloader

[DanielLeens]

Purpose

Replace the version-specific Pulsar/Netty/HK2 private-class preload workaround with a maintainable cleanup boundary.

Root cause

Pulsar can lazily resolve shaded Netty/Jersey implementation classes while closing producers, consumers, clients, and admins. SeaTunnel close paths can run from engine threads whose context classloader no longer points to the Pulsar connector, so hard-coding private helper class names only masks the symptom and will break across Pulsar dependency changes.

Changes

• Run Pulsar cleanup actions with the Pulsar connector classloader as the thread context classloader.
• Close source split readers before closing the shared Pulsar client.
• Stop periodic partition discovery before closing the Pulsar admin.
• Add unit coverage for classloader restoration and source cleanup order.

Validation

• ./mvnw -pl seatunnel-connectors-v2/connector-pulsar -am -nsu spotless:apply
• ./mvnw -pl seatunnel-connectors-v2/connector-pulsar -nsu test

seatunnel-engine-ui was not included because this PR only changes the Pulsar connector backend module.

[DanielLeens]

Thanks for the contribution. I reviewed the latest head from the Pulsar source/sink shutdown paths through the classloader and cleanup-order boundaries, and this looks good to me.

What this PR solves

• User pain: Pulsar producer / consumer / client / admin cleanup can also run from engine-managed threads. If the thread context classloader no longer points at the Pulsar connector, lazy class resolution during close can fail. On top of that, the previous close order left shared admin/client resources easier to shut down before their users were fully stopped.
• Fix approach: run Pulsar cleanup through PulsarConfigUtil.runWithConnectorClassLoader(...), stop the discovery executor before admin close, close split readers before the shared client, and preserve all cleanup failures instead of losing later ones.
• One-line summary: this is a targeted Pulsar shutdown-boundary fix, not a behavior change in normal read/write semantics.

Full execution path I checked

Pulsar task shutdown
  -> source reader / sink writer / committer / enumerator close
      -> producer / consumer / client / admin cleanup
  -> before this PR
      -> wrong TCCL can break lazy class resolution during close
      -> shared admin/client can be closed while readers or discovery still depend on them
  -> after this PR
      -> connector classloader is restored for cleanup
      -> discovery executor stops before admin close
      -> split readers close before shared client close
      -> cleanup failures are aggregated instead of truncating later cleanup

Key findings

1. The normal runtime path definitely hits this change because all Pulsar close paths now go through the helper.
2. This PR improves two real lifecycle boundaries at once: classloader context during cleanup, and shutdown ordering of shared resources.
3. The new tests cover the classloader boundary and the close-time contract on the writer/source side.
4. I do not see a reopened blocker on the current head.

Findings

• No blocking issues from Daniel's side on the latest head.

Conclusion: can merge

1. Blocking items

• None.

2. Suggested non-blocking follow-up

• None.

Overall, this is a precise fix for the Pulsar cleanup boundary and shutdown ordering, and I'm happy to approve it.