Fix qd8_f16_qb4w GEMM config getter always returning NULL on Arm

[notaJiminLee]

Problem

On Arm64, every QD8/F16/QB4W fully-connected op fails at runtime creation with xnn_status_unsupported_hardware, even though the microkernels are present in the binary and the hardware supports FP16 (verified on Apple M4: 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 Arm branch (it sets only mr / nr / log2_kr / planes / dqgemm). So on Arm64 the getter always returns NULL.

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

The sibling xnn_init_qd8_f16_qc4w_gemm_config() returns its config unconditionally (its init likewise does not set .arch). qd8_f16_qb4w is the only getter carrying this stray .arch guard.

Fix

Return the config unconditionally, matching the qd8_f16_qc4w sibling.

Verification

On Apple M4, a QD8/F16/QB4W linear .pte that previously aborted with unsupported_hardware now runs to completion (Model executed successfully). The qd8_f32_qb4w and qd8_f16_qc4w paths are unaffected.