Close the consumer when removeMessageConsumer removes it

[jcschaff]

Last of the JMS resource problems turned up while working through the export-progress
incident (#1837, #1838, #1839, #1842, #1844, #1845).

The leak

removeMessageConsumer only called stop(), which asks the polling thread to finish its
current loop:

if (context.getVCConsumer() == vcMessagingConsumer){
    try { context.stop(); } finally { consumerContexts.remove(context); }
    return;
}

The MessageConsumer, its session and its connection were left open. The broker therefore
went on dispatching to a consumer nobody was reading — and with a prefetch limit those
messages sit in its client-side buffer, undelivered and not redelivered until the
connection dies. Every VCell consumer is registered with an explicit prefetch limit
(MessageConstants.PREFETCH_LIMIT_*), so any removed consumer strands at least one message.

The fix

ConsumerContextJms.stopAndClose() stops the thread, waits for it to leave its receive()
— bounded by two polling intervals, the same budget VCMessagingServiceJms.close() already
allows — and then closes the consumer, session and connection. removeMessageConsumer uses
it.

Finding the context first and mutating the list afterwards also removes a
remove-while-iterating that only worked because of the immediate return.

Verification

removingAConsumerDoesNotStrandMessages registers a consumer, removes it, sends three
messages, then registers a replacement and requires all three to arrive. Control, with both
production files reverted to master and the test kept:

all 3 messages should reach the replacement consumer; a removed consumer must not
still be holding one ==> expected: <true> but was: <false>

Exactly one message stranded, as predicted by the prefetch limit of 1. vcell-server Fast
group: 61 passed.

This one was not hypothetical

It cost a full debugging cycle on #1845. A responder torn down by an earlier test in the
same class was still holding a prefetched message, so a later test failed in a way that
looked exactly like the concurrency bug that PR was fixing — four concurrent callers passed,
six did not. Running the same test against origin/master first is what ruled out the
change under test and pointed here instead.

In production the same shape means a request silently stranded whenever a consumer is
removed and re-registered: no error, no redelivery, just one message that never gets a
reply until the connection is torn down.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SY1XHgTZXZPqUECo2VBAWg