Discrepancy between SAADC Input Configuration (P0.04) and Physical Pin (P0.05) despite Full Chip Erase

Question

I am encountering a strange hardware/software mapping issue with the SAADC on an nRF52833 DK running on Zephyr (NCS) . Using VS Code nRF Toolchain and SDK (V3.2) 
 The issue is a persistent mismatch between the configured SAADC input and the actual physical pin being read. 
 The Problem: We are explicitly configuring the SAADC to sample from P0.04 (AIN2) . However, our observations suggest that the ADC is physically sampling P0.05 (AIN3) instead.

When we apply a signal to P0.04, the ADC reads 0 or noise.

When we apply a signal to P0.05, the ADC (configured for P0.04) reacts and reads the values.

Troubleshooting Steps Taken: To rule out any persistent register settings, board-level caching, or corruption:

We performed a complete factory reset

We re-flashed the firmware from a clean build state (pristine build).

Despite these steps, the crossover/mismatch issue persists.

Code Configuration: We are bypassing the Devicetree macros for the channel configuration to ensure direct control. Here is the configuration struct we are using:

static const struct adc_channel_cfg channel_cfg = {
 .channel_id = 0 ,
 .gain = ADC_GAIN_1_6,
 .reference = ADC_REF_INTERNAL,
 .acquisition_time = ADC_ACQ_TIME_DEFAULT,
 .input_positive = NRF_SAADC_INPUT_AIN2, // Intending to read P0.04 
};

My Questions:

Is there any known errata or internal routing conflict on the nRF52 series that could cause NRF_SAADC_INPUT_AIN2 to be internally routed to or shorted with the AIN3 (P0.05) line?

Since a full chip recover/erase did not solve the issue, could this indicate a damaged internal mux on the chip, or is there a hidden default state in the Zephyr board definition files that might override our manual C-struct configuration?

We need to confirm if this is a hardware defect or a lower-level software mapping anomaly.