fix(prop,mtk): improve dump metadata extraction

[bluehomewu]

Summary

Improve firmware metadata extraction in a few common failure cases.

• Fix the ro.system.board.platform fallback lookup.
• Add a fallback path that scans extracted build*.prop files when fixed prop paths do not contain metadata.
• Keep raw MediaTek modem images as-is instead of trying to extract them as archives.

Details

The platform fallback had a malformed rg invocation, so ro.system.board.platform could never be read from system build props.

Some firmware packages expose useful metadata in extracted build.prop files outside the existing fixed lookup paths. This adds a final fallback that collects extracted build.prop, build_*.prop, and *build*.prop files and queries them only when the existing lookup chain does not find a value.

MediaTek modem images can be raw md1rom / MOLY blobs rather than archive or filesystem images. Attempting to extract them with fsck.erofs or 7z produces noisy failures such as:

Cannot open the file as archive

These images are now detected and kept as modem.img.

Tested

• bash -n dumpyara.sh
• Verified MTK firmware with raw modem.img no longer reports a 7z archive extraction error.
• Verified metadata fallback fills README fields when props are not available from the fixed vendor/system paths.

[akhilnarang]

Thanks for these — the ro.system.board.platform bugfix and the MTK raw-modem handling are solid, and the whole thing passes bash -n. Two requests before merge, one important and one optional. Both validated empirically with real rg/strings runs (cross-checked via gpt-5.6-sol).

1. (please fix) Pin file order in prop_value() — see inline on the rg call. When the same key exists in multiple build*.prop files (very common: system vs vendor vs my_product all carry e.g. ro.build.id), rg searches files in parallel and its output order is not pinned to argument order. In testing the first line was often stable, but the multi-file output ordering genuinely varied run-to-run (~82/100 vs ~18/100 across iterations), so head -1 is not guaranteed to return the value from the file you intend. The for key in "$@" loop shows you want deterministic priority — that intent is preserved across keys but lost across files. Adding --sort path pins the order (single-threaded, follows the order in PROP_FILES, which you already build via sort -z).

2. (optional) ^(md1rom|MOLY\.) anchoring — see inline on the detection helper. Confirmed the ^ anchors to the start of each strings-emitted run, so an embedded ...MOLY.WR8 inside a longer printable run won't match. For genuine md1rom magics this is fine (standalone), but MOLY. version banners sometimes sit mid-string. Since a miss just falls back to the existing extraction attempt (current behavior), this is low-risk — flagging in case you want more robust detection (drop the ^, or use \b).

Nit (optional): the *build*.prop glob is a superset of the build.prop/build_*.prop patterns in the same find, so the first two are redundant.

[akhilnarang]

rg searches multiple files in parallel and does not pin output order to argument order, so head -1 can return a value from a non-intended file when the same key appears in more than one prop file (e.g. ro.build.id in both system and vendor). Verified empirically: the full multi-file output order varied run-to-run.

Suggested change

	value=$(rg -m1 -INoP --no-messages "^${escaped_key}=\\K.*" "${PROP_FILES[@]}" | head -1)
	value=$(rg -m1 --sort path -INoP --no-messages "^${escaped_key}=\\K.*" "${PROP_FILES[@]}" | head -1)

--sort path makes the winner deterministic and matches the sort -z ordering you already use to build PROP_FILES.

[akhilnarang]

Optional: the ^ anchors to the start of each run strings emits, so md1rom/MOLY. only match when they begin a printable run — an embedded ...MOLY.WR8 inside a longer run won't match (verified). For real md1rom magics this is fine; MOLY. banners can appear mid-string, so if you want more robust detection consider dropping the ^ or using \b. Not blocking — a miss just falls back to the existing extraction path.