feat(nvcf-ui): import the self-hosted UI into the monorepo

[balajinvda]

Why

The self-hosted NVCF UI is developed outside this repository today. Now that
every first-party service builds from the root Bazel module here, the UI should
live alongside them so it shares one build, one CI matrix, one dependency
audit, and one release path instead of maintaining its own.

The UI maintainers are ready to start the cutover, and the source is reported to
already carry license headers.

Proposed location

src/uis/nvcf-ui, matching the existing src/clis/nvcf-cli convention.

An earlier attempt placed it under the control-plane services, on the grounds
that this is where it is installed. Grouping by artifact kind rather than by
deployment topology is the better fit: the UI is a shipped user-facing artifact
like the CLI, not a control-plane service.

What this needs

1. Import the source into src/uis/nvcf-ui.

2. Bazel wiring for Node.js. This repository builds Go, Rust, and Java; no
   JavaScript or TypeScript ruleset is wired today. This needs a ruleset
   decision, a BUILD.bazel layout for the UI, and a row in the
   .github/workflows/bazel.yml matrix so the subtree is built and tested on
   its own changes.

3. Dependency auditing for Node.js. tools/collect-dependencies currently has
   collectors for Go, Helm, Java, Python, and Rust. There is no npm collector,
   and node_modules appears only in directory skip lists. Without one, the
   UI's third-party tree will not reach dependencies.md or NOTICE. This is
   a prerequisite for the dependency review, not a follow-up.

4. Versioning and release. The UI uses semantic-release today, tagging on merge
   to main. Services in this repository already semantic-version from merges to
   main, so the schemes are close; expect small adjustments rather than a
   rewrite. The publish destinations are configured outside this repository and
   are unaffected by the import itself.

5. License headers. Reported present already; confirm with
   tools/ci/check-license, which scans the whole repository rather than only
   the new subtree.

6. Security and quality scanning. Decide whether the UI is registered as its own
   project or folded into an existing one. Source-level scanning is not
   currently configured for it; container scanning happens today as part of its
   existing publish flow.

Open questions

• Patent review: NVCF patents are already cleared for open source. Confirm the
  UI falls under that existing approval rather than needing its own pass.
• Third-party dependency review and approval for the UI's dependency tree, which
  cannot be completed until item 3 above can enumerate it.
• Two NVIDIA packages the UI depends on are already published publicly:
  @nvidia/foundations-react-core and @nvidia/foundations-tailwind-plugin.

Sequencing

Items 1 through 3 are the blocking path: the source has to land somewhere before
it can be built, and the dependency collector has to exist before the dependency
review can be completed. Items 4 through 6 can proceed in parallel once the
subtree exists.