webgpu: use naive reduction

[xhcao]

Use naive reduction when the output size of ReduceMean is far greater than reduce size. Shared reduction method may need to transpose input, which costs much time.

Description

Motivation and Context

[xhcao]

When I run florence-2-base-vision-encoder-fp16-0.5-fp32 with input [batch_size:1, height:768, width:768], 10 ReduceMean nodes using shared reduction method cost much time,
ReduceMean|Transpose 6.51 "inputs[0] = {1,128,36864} outputs[0] = {1,36864,128} "
ReduceMean 0.30 "inputs[0] = {1,36864,128} outputs[0] = {1,1,36864} "

It is heavy to transpose the input. If we use the naive method,
ReduceMean 0.11 "inputs[0] = {1,128,36864} outputs[0] = {1,1,36864} "

The model's total time is from ~340ms to ~270ms.

[Copilot]

Pull request overview

Updates the WebGPU reduction kernel dispatch heuristic to prefer the naive reduction implementation for certain ReduceMean shapes, aiming to avoid transpose overhead that can dominate runtime when the reduced dimension is small but the output is very large.

Changes:

• Adjusts the use_naive_reduction selection logic in ReduceKernel::ComputeInternal.
• Adds a ReduceMean-specific threshold to route some cases to ReduceNaiveProgram.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[xhcao]

@jchen10 PTAL

[xhcao]

@qjia7 PTAL, thanks

[xhcao]

@guschmue PTAL

[xhcao]

@guschmue It seems that the CI failure is not related with this PR, please re-trigger the bots again, thanks.

[xhcao]

Rebase the code.

[xhcao]

@guschmue Please take a look it, thanks.

[jchen10]

@guschmue Just a gentle ping.