Bump vendored XNNPACK to include qd8_bf16_qb4w subgraph FC (#21400)

## Summary

Bumps the vendored XNNPACK submodule
(`backends/xnnpack/third-party/XNNPACK`) from `1adaa7c` to `92a7ad5`
(current `google/XNNPACK` master).

The key change picked up in this range is
[google/XNNPACK#10818](https://github.com/google/XNNPACK/pull/10818),
which adds the **`qd8_bf16_qb4w` fully-connected path to the subgraph
layer**. Before this, XNNPACK's subgraph layer could build
`qd8_f32_qb4w` and `qd8_f16_qb4w` dynamic-quant FC subgraphs but had no
bf16-scale variant, so a bf16 activation feeding an `8da4w`
(int8-dynamic-activation / int4-weight, blockwise) linear could not be
lowered/run through XNNPACK.

This bump is a prerequisite for bf16 dynamic-quant (`8da4w`) delegation
to XNNPACK; the ExecuTorch-side backend changes that consume it are in a
follow-up PR.

## Test plan

- Built ExecuTorch with the bumped submodule (x86, XNNPACK backend).
- Exported `google/gemma-3-1b-it` with `--dtype bfloat16 --qlinear 8da4w
--qembedding 8w` via `optimum-executorch` (XNNPACK recipe, custom SDPA +
KV cache) — lowering succeeds and the FC nodes delegate as
`qd8_bf16_qb4w`.
- Runtime forward on the resulting `.pte` produces finite `bfloat16`
logits with argmax matching the fp32 and bf16-no-quant baselines.

cc @GregoryComer @digantdesai @cbilgin