getByNames in both CategoryFinderImpl and TagFinderImpl returned results sorted by the store's default sort (priority/creationTimestamp/name) rather than preserving the caller-provided names order.

Changes:

• After fetching matched items via Queries.in(...), collect results and re-sort using a pre-built HashMap<name → index> derived from the input collection — O(n log n), avoids repeated indexOf scans
• Applied identically to CategoryFinderImpl.getByNames and TagFinderImpl.getByNames
• Added tests to both CategoryFinderImplTest and TagFinderImplTest verifying order is preserved when the store returns items in a different order than requested

// Before: returned [category-bar, category-foo] despite input order
categoryFinder.getByNames(List.of("category-foo", "category-bar"))

// After: returns [category-foo, category-bar] matching input order

What type of PR is this?

/kind bug

What this PR does / why we need it:

getByNames in CategoryFinderImpl and TagFinderImpl ignored the order of the input names collection, returning results sorted by the store's default comparator instead. This fix post-sorts results using a name→index map built from the input, preserving caller-specified order.

Which issue(s) this PR fixes:

Special notes for your reviewer:

The same bug existed in TagFinderImpl.getByNames and is fixed in the same commit.

Does this PR introduce a user-facing change?

修复通过 `categoryFinder.getByNames` 和 `tagFinder.getByNames` 获取的结果顺序不对的问题