[MINOR] Add daily npm audit remediation workflow

[jongyoul]

What is this PR for?

Add a daily and manually dispatchable workflow that detects high/critical npm audit failures in zeppelin-web-angular/projects/zeppelin-react and prepares a validated lockfile-only remediation PR.

The workflow never pushes to master and never merges a PR. After all checks pass, it writes only to the dedicated automation/npm-audit-fix-zeppelin-react branch and opens or updates a draft PR.

Duplicate prevention is content-based:

• the workflow serializes runs with one concurrency group;
• it always uses the same upstream automation branch;
• it queries PRs by the exact upstream owner and branch;
• if the generated lockfile blob is already present in the latest open, closed, or merged automation PR, it does not push or create another PR;
• if an open automation PR exists with different lockfile content, it updates that PR;
• closing an unchanged automation PR is respected, so the same fix is not recreated the next day.

The write job is separated from the read-only preparation job. It runs only for scheduled/manual events in apache/zeppelin, and only after all of these safeguards pass:

• the audit failure contains a real high/critical vulnerability report;
• npm audit fix --package-lock-only --ignore-scripts changes exactly the React lockfile and never uses --force;
• clean parent and React installs complete;
• the repaired lockfile passes audit, lint, tests, and production build.

What type of PR is it?

Improvement

Todos

• Validate the current lockfile-only remediation path locally.
• Validate the workflow with actionlint.
• Obtain ASF Infrastructure approval before enabling an Action to push an official source-repository branch, as required by the ASF GitHub Actions policy.
• Confirm that the repository setting allowing GitHub Actions to create pull requests is enabled.

What is the Jira issue?

N/A for this draft. A Jira can be created before marking the PR ready if required.

How should this be tested?

The current master lockfile was tested with Node 22 and npm 10.9.4 using the same sequence as the workflow:

• initial audit: 3 high, 0 critical vulnerabilities;
• lockfile-only audit fix: only zeppelin-react/package-lock.json changed;
• repaired audit: 0 vulnerabilities;
• ESLint: passed;
• Vitest: 14/14 passed;
• production webpack build: passed (existing asset-size warning only);
• YAML parsing, actionlint v1.7.12, and git diff --check: passed.

For generated PRs, GitHub documents that pull_request checks created through GITHUB_TOKEN start in an approval-required state. A maintainer can approve those runs; the remediation workflow also completes audit/lint/test/build before creating the PR. See GitHub's GITHUB_TOKEN documentation.

Screenshots (if appropriate)

N/A

Questions:

• Does the license files need to update? No.
• Is there breaking changes for older versions? No; automatic fixes are restricted to compatible lockfile-only changes.
• Does this needs documentation? The workflow and generated PR body describe the behavior; no user-facing documentation is changed.