Update workflow-js Cargo.toml for HarmonyOS build

[shenyongqing]

rquickjs doesn't ship pre-generated bindings for HarmonyOS/OpenHarmony, need to generate there.

Summary

Testing

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features
• cargo test --workspace --all-features

Checklist

• Updated docs or comments as needed
• Added or updated tests where relevant
• Verified TUI behavior manually if UI changes
• Harvested/co-authored credit uses a GitHub numeric noreply address

[github-actions]

Thanks @shenyongqing for taking the time to contribute.

This repository is observing a maintainer-managed PR intake gate in dry-run mode, so this pull request is staying open. This note helps maintainers prepare the allowlist before any enforcement is considered.

Please read CONTRIBUTING.md for the expected contribution shape. A maintainer can grant recurring PR access by commenting /lgtm on a pull request.

[Hmbown]

Roadmap triage: this PR is now in v0.9.1 and linked to #2970 as the rquickjs/workflow-js build slice. It does not by itself close the tier-2 target issue; CI, sandbox, clipboard, and docs work remain there.

[Hmbown]

Thanks @shenyongqing — this is the right narrow shape for the OHOS fix, and I’ve placed it in the v0.9.1 queue.

I replayed the commit onto current main (17ac2681) and verified:

• rustc --print cfg --target aarch64-unknown-linux-ohos reports target_env="ohos"
• cargo fmt --all -- --check
• cargo metadata --no-deps --format-version 1
• cargo check -p codewhale-workflow-js
• git diff --check origin/main...HEAD

All of those pass. Before this is merge-ready, could you please:

1. amend the commit with a Signed-off-by trailer (git commit --amend --signoff && git push --force-with-lease), and
2. post the exact cargo check --target aarch64-unknown-linux-ohos -p codewhale-workflow-js receipt from an environment with OHOS_NATIVE_SDK configured?

I don’t have an OHOS SDK in this review environment, so I’m treating the target check as the remaining proof rather than claiming it from the host-only build.

[Hmbown]

Retained for v0.9.1. The six-line HarmonyOS rquickjs bindgen change is isolated and still relevant, but this 163-behind head lacks a Signed-off-by line, current-base CI, and an exact OHOS-target build receipt with OHOS_NATIVE_SDK. We should land it as a credited fresh harvest if the contributor branch cannot be updated; #2970 must remain open because this covers only the workflow-js slice.

[Hmbown]

Hi @shenyongqing — thank you for this contribution! The approach in this PR (activating rquickjs's bindgen feature for target_env = "ohos" so QuickJS bindings are generated at build time) is exactly right, and we want to land it with your authorship fully intact.

Rather than merging this PR directly, we've carried your commit onto a maintainer replacement lane in #4459. That lane rebases your work onto current main, reruns the focused gates, and adds one SDK-free CI guard (scripts/release/check-ohos-deps.sh now proves the OHOS target keeps the rquickjs-sys bindgen feature edge, using only cargo tree metadata). Your commit is preserved as-is — author Shen Yongqing <26758802+shenyongqing@users.noreply.github.com>, same change, no squash — and you're credited in the changelog, docs/CONTRIBUTORS.md, and the replacement PR body.

The replacement stays DRAFT until someone produces a real HarmonyOS SDK receipt (source scripts/ohos-env.sh && cargo check --locked --target aarch64-unknown-linux-ohos -p codewhale-workflow-js), so nothing is landing ahead of verification. This covers the workflow-js slice of #2970 only; the issue stays open.

We're leaving this PR open for the steward to close once the replacement lands. Thanks again for the clean fix! 🐋

[Hmbown]

Closing with the lineage recorded: the OHOS bindgen approach you pioneered here has landed on main through #4470 (merged), which implements the same cfg(target_env = "ohos") bindgen targeting plus portable-pty gating and the PowerShell libclang setup, with a real-SDK check receipt.

You are credited in docs/CONTRIBUTORS.md for the original approach, and the SDK-free bindgen-edge guard from the #4459 review lane is carried forward in #4472.

The replacement was needed because the original PR required a rebase plus review-hardening; thank you for the groundwork — the HarmonyOS slice of #2970 is better for it.

[Hmbown]

The remaining Windows final-link wrapper gap from the OHOS bindgen work is now merged in #4503 at 8ab67a0bc03ac78406677339f3e4e3714e138885. @shenyongqing’s original bindgen approach and @shenjackyuanjie’s validation remain credited; static cross-platform gates pass, with real SDK/device linking still explicitly pending.