Fix qd8_f16_qb4w GEMM config getter always returning NULL on Arm

[outum1500]

Problem

On Arm, every QD8/F16/QB4W fully-connected op fails at runtime creation with xnn_status_unsupported_hardware, even though the microkernels are built and the hardware supports FP16 (reproduced on Apple M4: hw.optional.arm.FEAT_FP16=1, hardware config reports neon_fp16_arith / neon_dot / neon_i8mm).

Root cause

xnn_init_qd8_f16_qb4w_gemm_config() ends with:

return qd8_f16_qb4w_gemm_config.arch ? &qd8_f16_qb4w_gemm_config : NULL;

but init_qd8_f16_qb4w_gemm_config() never assigns .arch on any branch (it sets only mr / nr / log2_kr / planes / dqgemm). So qd8_f16_qb4w_gemm_config.arch stays 0 and the getter always returns NULL on Arm.

This stays hidden until the convert -> fully_connected packed-LHS path sets XNN_FLAG_INLINE_LHS_PACKING; setup_variant_and_gemm_config() then receives a NULL gemm config and returns xnn_status_unsupported_hardware, aborting runtime creation.

The sibling getters xnn_init_qd8_f16_qc4w_gemm_config(), xnn_init_qd8_f16_qc8w_gemm_config() and xnn_init_qd8_f32_qb4w_gemm_config() return their config unconditionally and likewise do not set .arch. qd8_f16_qb4w is the only one in this family carrying a stray .arch guard.

Fix

Return the config unconditionally, matching the sibling getters.

Test

On Apple M4, a QD8/F16/QB4W linear model that previously aborted at runtime creation with unsupported_hardware now runs to completion. The qd8_f32_qb4w, qd8_f16_qc4w and qd8_f16_qc8w paths are unchanged.

[dsharlet]

Shouldn't we set arch, rather than ignoring it?

I think this is only used on x86 to do the qdu8 rewrite, but I'd rather not guess...