Add span for picker

[gyliu513]

Sub task for #1483

[chinmaychahar]

/assign

[chinmaychahar]

Hey @gyliu513, What should the span be named pick_endpoint (like existing spans) or llm_d.epp.picker (like the dotted style in #1483)? Any attributes needed beyond type, name, candidate count, and selected count?

[gyliu513]

@chinmaychahar Good question. Use pick_endpoint, not llm_d.epp.picker.

#1565 standardized our tracing: span names are now short snake_case verb phrases (pick_pd_profile, score_prefix_cache, prepare_disaggregation, forward_request), and the dotted llm_d.epp.* prefix was removed from span names. The namespacing moved into the OTel instrumentation scope instead. So start the span with tracing.Tracer(schedplugins.TracerScope) and trace.WithSpanKind(trace.SpanKindInternal), matching the other scheduling spans.

The scope constant lives in pkg/epp/framework/plugins/scheduling/constants.go (schedplugins.TracerScope). The pickers are subpackages under that tree (picker/maxscore, picker/weightedrandom, picker/random), so import the parent package and reference schedplugins.TracerScope — exactly like score_prefix_cache does in scorer/preciseprefixcache/precise_prefix_cache.go.

For attributes, the dotted namespace stays on the keys:

• llm_d.epp.picker.candidate_endpoints (Int) and llm_d.epp.picker.selected_endpoints (Int) for the counts
• reuse the shared gen_ai.request.model and gen_ai.request.id keys, the same way the scorer and profile-handler spans do

Following the score_prefix_cache reference, you don't need separate type/name attributes on the span — that span doesn't set them, and pick_endpoint already identifies the operation. If you do want them, the values are available via p.TypedName().Type / .Name, no extra computation needed. So just candidate_endpoints + selected_endpoints plus the shared gen_ai.request.* keys.

Note there are three picker implementations — check whether the span should go in all of them or just maxscore.