refactor: clean pipeline for multi-output resolution in WidgetSelectDropdown

## Summary

The multi-output job resolution logic introduced in #10131 uses an ad-hoc pattern — a `shallowRef` map (`resolvedByJobId`), a bare `Set` (`pendingJobIds`) for in-flight tracking, and a `watch` block with a cancellation flag — directly inside `WidgetSelectDropdown.vue`. While functional, this approach mixes async coordination concerns into the component and will become harder to maintain as the logic grows.

## Goal

Refactor the resolution logic into a clean, self-contained pipeline (e.g., a dedicated composable such as `useMultiOutputResolution`) that:

- Encapsulates LRU caching, in-flight deduplication, and cancellation.
- Exposes a clean reactive interface to the component (e.g., `resolvedOutputs` computed/ref).
- Is independently testable without mounting the full component.
- Can be cleanly removed or no-op'd once the backend Assets API returns full outputs in list responses (the planned migration noted in #10131).

## Context

- PR: #10131 (comment: https://github.com/Comfy-Org/ComfyUI_frontend/pull/10131#discussion_r2963657866)
- Requested by: @DrJKL
- The current implementation is explicitly a consumer-side workaround and is expected to be temporary.

## Acceptance Criteria

- [ ] Extract multi-output resolution into a composable (e.g., `useMultiOutputResolution`).
- [ ] Component `WidgetSelectDropdown.vue` delegates entirely to the composable.
- [ ] Unit tests cover the composable in isolation.
- [ ] No behavioral regression for single-output or multi-output jobs.

┆Issue is synchronized with this [Notion page](https://www.notion.so/Issue-10379-refactor-clean-pipeline-for-multi-output-resolution-in-WidgetSelectDropdown-32a6d73d3650816fbb33dfe27f8a5474) by [Unito](https://www.unito.io)