Split the "monolithic" `precise-prefix-cache-scorer`

[vMaroon]

precise-prefix-cache-scorer is a monolith: tokenization, KV-block
indexing, ZMQ subscriber lifecycle, speculative indexing, and scoring
all in one Scorer plugin.

Split each responsibility into the plugin type built for it; let the
generic prefix-cache-scorer read from whichever producer is configured.

• Tokenization → token-producer (Add external tokenizer PrepareData plugin and TokenizedPrompt scorer support #694)
  • deprecate UDS-backend in token-producer and suggest configuring the vllm render instead #1079 (comment)
• Index + subscribers + match-info → precise-prefix-cache-producer ([2/3] feat(precise-prefix-cache): add precise-prefix-cache-producer #1112)
• Recommend prefix-cache-scorer with prefixMatchInfoProducerName: precise-prefix-cache-producer for precise config ([2/3] feat(precise-prefix-cache): add precise-prefix-cache-producer #1112)
• Deprecate the legacy scorer ([3/3] feat(precise-prefix-cache): scorer deprecation + maximal implicit use of the new producer #1121)
• Make prefix-cache-scorer hook with the precise-prefix-cache-producer without explicit configuration is present

[ahg-g]

Splitting is done and the default is now to use the refactored plugins, right? if so, I think we can close this one and track the deprecation of the legacy scorer in it own PR

[hexfusion]

@vMaroon one more item on the list could you use help or is it in flight?

[vMaroon]

The last item requires revisiting some semantics / design choices IMO - feel free to give it a go (need to start with a discussion). I would want the prefix-cache-scorer and consumers in general to automatically hook up with any producer that produces a key they depend on. Though I think @ahg-g may disagree here considering his preference for explicitness.

We can discuss.

[hexfusion]

Will raise a separate issue

[ahg-g]

The last item requires revisiting some semantics / design choices IMO - feel free to give it a go (need to start with a discussion). I would want the prefix-cache-scorer and consumers in general to automatically hook up with any producer that produces a key they depend on. Though I think @ahg-g may disagree here considering his preference for explicitness.

We can discuss.

I am actually all for automatic configuration if we can find a good solution; but should we create a separate issue for it and the deprecation of the legacy scorer and consider this one?