feat: scaffold --target harmonyos[-simulator] (PR A for #113)

[proggeramlug]

First of three PRs tracking HarmonyOS NEXT support (#113). Pure scaffolding — every change is an additive arm in an existing match, unreachable unless --target harmonyos or --target harmonyos-simulator is passed. No behavior change for any other target.

What's in scope

• rust_target_triple / resolve_target_triple: harmonyos → aarch64-unknown-linux-ohos, harmonyos-simulator → x86_64-unknown-linux-ohos (DevEco emulator).
• find_library candidate suffix (_harmonyos) mirroring the _watchos / _ios / _tvos convention for npm-distribution library naming.
• find_ui_library → libperry_ui_harmonyos.a (the crate lands in PR C).
• parse_native_library_manifest target_key → "harmonyos" so package.json authors can declare perry.nativeLibrary.targets.harmonyos.
• UI-crate selector arm → perry-ui-harmonyos.
• is_mobile feature filter includes harmonyos[-simulator] so --features plugins is stripped (dlopen isn't practical under HarmonyOS's sandbox).
• __platform__ = 7 reserved for HarmonyOS. Ordered before the linux arm in the if t.contains("ohos") chain because the OHOS triple is *-unknown-linux-ohos — naive contains(\"linux\") would misclassify it as 4.

Deliberately not in scope

• Platform enum variant: publish.rs:627 and run.rs:1687-1802 exhaustively match every variant. Adding one forces premature behavior decisions (what does perry publish --platform harmonyos do? what does perry run --target harmonyos do?). Those land with PR B.3 alongside the HAP bundler. compile takes Option<String>, so --target harmonyos works today without this change.
• .so output mode, NAPI entry, ArkTS shim, HAP bundler, OHOS SDK detection, linker invocation — PR B (already in progress on harmony-os branch).
• perry-ui-harmonyos crate + TS→ArkTS emitter — PR C.

Verification

• cargo build --release -p perry -p perry-codegen — clean.
• perry compile hi.ts (no target) — byte-equivalent output, runs.
• perry compile hi.ts --target harmonyos — fails with clear error Could not find libperry_runtime.a (for target \"harmonyos\"), search paths include target/aarch64-unknown-linux-ohos/release/... and the _harmonyos suffix — proving both new arms are wired. rustc additionally suggests rustup target add aarch64-unknown-linux-ohos, confirming the triple is upstream-recognized (Tier 2, host tools).
• rustup target add {aarch64,x86_64}-unknown-linux-ohos both succeed on stable — no nightly needed (unlike watchOS/tvOS).

Test plan

• CI passes
• Existing --target {macos,ios,android,watchos,tvos,linux,windows,web} produce byte-equivalent output to main
• --target harmonyos fails with the expected "runtime not found" error chain