Add NT98513 and NA51023 identification on MIPS

[dpiers]

MIPS cameras identifying as Novatek NA51023 currently miss Novatek detection. Add a dedicated MIPS detector for the complete model token, report family nt9851x, and refine the name to NT98513 only when /etc/profile_prjcfg contains the exact export CHIP="98513" declaration. Missing or different profiles retain NA51023. The profile is parsed as text. Other model tokens and the unverified ARM chip-ID proc interface cannot select this MIPS route.

The identity is backed by an NT98513 firmware dump's embedded model, novatek,na51023-soc compatible and factory CHIP declaration. The software discriminator selects a HAL that declines unsupported sensor-bus operations. This adds identification only; no camera was available to validate boot or capture.

The new refinement, family case and HAL behavior are compiled only for MIPS. Existing ARM/AArch64 parsing and behavior are preserved. With the exact ARM32 CI SDK and firmware-style size configuration, both ipcinfo variants are byte-for-byte identical to the PR base: 47,356 bytes for all vendors and 38,492 for none. The size allowance is unchanged.

Tests use the actual parser, detector and platform dispatch, covering complete-token rejection, missing/mismatched profiles, ARM-ID isolation, legacy chip IDs and rejected sensor probing. Three explicit architecture fixtures run in native CI. Validation passed: full native and MIPS builds, all 13 native tests, sensor extraction pipeline/self-tests, three architecture fixtures under ASan/UBSan, and all three fixtures as MIPS binaries under QEMU. The local MIPS compiler is Debian GCC 12, MIPS32r2 o32 hard-float glibc; this does not establish compatibility with the camera's soft-float uClibc runtime.

[openipc-ai]

Review of 4afe7c7: no bugs found. novatek_test builds and passes on this head.

Checked:

• Profile regex (src/hal/novatek.c): ^export CHIP="(98513)"[[:space:]]*$ accepts a trailing newline or CRLF and rejects the commented-out, longer-number and command-suffixed lines the test feeds it.
• Model regex: ^Novatek ([A-Z]+[0-9]+)([[:space:]]|$) still returns only the part name, since line_from_file reads the first capture group. "Novatek NA510xx" and "Novatek NA510xx evb" still match. One thing to confirm: a model like Novatek NA51089_EVB would no longer match. I don't know of a board that uses that form, so I'm not treating it as a bug.
• CHIP_NA51023 = 0x51023: no clash in getchipfamily(), padmux_ops() or novatek_gpio's group_pads(); an unknown generation falls through to "no table" / "unsupported".
• Early return in novatek_setup_hal(): open_spi_sensor_fd = NULL and possible_i2c_addrs = NULL are both handled by their callers, and the bus open that returns -1 means the sensor sweep never opens a device. Side effect: ipctool i2cget/i2cdump print "Device not found" on NA51023. That looks intended and isn't a regression, since the chip wasn't detected before.
• MIPS dispatch (src/chipid.c): the Ingenic entries are still tried first, filtered by their "isvp"/"ingenic" patterns; the new Novatek entry runs only after they fail and only reads Novatek-specific files.
• Test wiring: the line_from_file macro redirect and --wrap on open don't affect the real parser, and the __mips__ trick holds because every header is included before chipid.c is pulled in.