[JENKINS-35272] Launcher's afterDisconnect() method is called twice

[Anvarjon7]

Fixes #17204

Takes over the work from #26188 to fix JENKINS-35272, addressing the Windows test failure that caused the previous attempt to be reverted.

Root Cause
When an agent disconnects, SlaveComputer.java executes launcher.afterDisconnect() from both the explicit disconnect() thread and the onClosed() channel listener. This caused duplicate teardown actions, such as shutting down VMs twice.

Why the Previous Fix Failed on Windows (UnsupportedRemotingAgentTest)
The previous attempt used a non-blocking AtomicBoolean to prevent the second call. However, if the test framework triggered a disconnect while the background Remoting thread was already killing the process, the test framework's thread would instantly return false (thinking the job was done) and proceed to the JUnit @TempDir cleanup phase. On Windows, this caused an AccessDeniedException because the background thread was still holding the file lock on unsupported-agent.jar while killing the process.

The Solution
Instead of an AtomicBoolean, this PR introduces a synchronized(disconnectLock) block around the execution flag.

• It ensures afterDisconnect() is only ever executed once.
• It forces any subsequent calling threads to block and wait until the first thread has fully completed the teardown logic.
• This restores the synchronous contract expected by the test framework, ensuring that by the time a test finishes, the agent process is completely dead and file locks are gracefully released.

Testing done

Verified locally on Windows native CLI. Executed mvn test -Dtest=UnsupportedRemotingAgentTest which now consistently passes, confirming the file-lock race condition is fully resolved and the asynchronous disconnect sequence safely completes before the test teardown.

Screenshots (UI changes only)

N/A

Proposed changelog entries

• Prevent afterDisconnect() from being called twice when an agent disconnects

Proposed changelog category

/label bug

Proposed upgrade guidelines

N/A

Submitter checklist

• The issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood. Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, new or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives.
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@jenkinsci/core-pr-reviewers

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.