[Bugfix] Fix memory leak and broken metrics in UCMBlendConnector

[SuperMarioYL]

Purpose

Fix two functional bugs in UCMBlendConnector that affect production serving reliability.

Modifications

Bug 1: requests_blend_meta memory leak

build_connector_meta cleans up self.requests_meta for finished requests (line 466) but never cleans up self.requests_blend_meta. Since get_num_new_matched_tokens adds an entry to requests_blend_meta for every request (line 399), this dict grows unboundedly for the lifetime of the process.

Each BlendRequestMeta holds block hashes, ChunkMetaData objects, and stage info, so in long-running serving scenarios the memory impact is significant.

Fix: Add self.requests_blend_meta.pop(request_id, None) alongside the existing cleanup.

Bug 2: self.monitor AttributeError crashes metrics path

When self.metrics_config is enabled, the blend connector calls self.monitor.update_stats("ConnStats", {...}) (line 386). However, self.monitor is never defined — the parent class UCMDirectConnector uses the module-level ucmmetrics.update_stats({...}) API instead.

This means any blend request with metrics enabled raises AttributeError: 'UCMBlendConnector' object has no attribute 'monitor'.

Fix: Replace self.monitor.update_stats(...) with ucmmetrics.update_stats(...) to match the parent class pattern.

Test

• black --check and isort --check --profile=black pass on the modified file.
• Both fixes are mechanical corrections to match the parent class behavior.

[SuperMarioYL]

The CI failure in lint-and-unit-tests / cpp_gtest is in the UCLoggerPerfTest.MultiThreadPerfUCInfoVsRateLimit performance test, which appears to be a pre-existing flaky test unrelated to this PR's changes (this PR only modifies Python files in ucm/integration/vllm/blend_connector.py). Could a maintainer trigger a CI re-run? Happy to make any code adjustments if needed.