refactor: Migrate to DefaultBlackListMatcher, remove BlackListManager singleton

[JusterZhu]

Summary

Both the legacy BlackListManager singleton and the new BlackListConfig/DefaultBlackListMatcher coexist. The plan calls for migrating to the new matcher injection model and removing the old singleton.

Current State

• BlackListManager (global singleton, thread-safe with lock) is used throughout the core flow: ClientUpdateStrategy.InitBlackList(), GeneralUpdateBootstrap.InitializeFromEnvironment(), GeneralUpdateBootstrap.InitBlackList()
• BlackListConfig (immutable record) and BlackListConfigBuilder are implemented and accepted via ConfigureBlackList()
• DefaultBlackListMatcher implements IBlackListMatcher but is never injected into StorageManager/FileTree/Pipeline
• The plan's design is: BlackListConfig -> IBlackListMatcher -> StorageManager / FileTree / Pipeline — injection-based, immutable

Expected

1. StorageManager, FileTreeEnumerator, PipelineBuilder accept IBlackListMatcher via constructor injection
2. GeneralUpdateBootstrap resolves IBlackListMatcher from BlackListConfig and passes it through
3. Remove BlackListManager singleton entirely
4. BlackListConfig.Empty serves as the default (no filtering)

Benefits

• Single source of truth for blacklist configuration
• Testable: matcher can be mocked in unit tests
• No global mutable state

Ref

Refactoring plan v2: Sub Issue 9 (BlackList)