fix: Build embedded UI from local source

[franciscojavierarceo]

What changed

• Backport fix: Build embedded UI from local source #6525 to v0.64-branch.
• Update make build-ui to build the checked-out ui/ source and copy the generated build into sdk/python/feast/ui/build.
• Keep build-ui-local as an alias for the same build path.
• Backport the explicit MCP enablement guard from master so mocked config does not accidentally mount MCP routes in unit tests.
• Backport the master REST route registration test simplification so the test verifies router inclusion directly instead of depending on mocked RestRegistryServer construction side effects.
• Backport the master allowlist comment for the OpenLineage placeholder API key so detect-secrets --all-files passes on the release branch.

Why

feast ui packages the embedded React app from sdk/python/feast/ui/build. The previous release build target pulled @feast-dev/feast-ui --latest from npm, but npm's latest published package is still 0.57.0. That stale UI treats registryPath as a monolithic registry blob URL, so with the newer Python server generating /api/v1, it requests GET /api/v1 and receives a 404.

Building the embedded UI from the repo-local ui/ source keeps the frontend bundle aligned with the REST-backed Python UI server for the 0.64 release branch.

The test-only backports are included because v0.64-branch unit tests use a MagicMock config. Without requiring mcp.enabled is True, the mock is truthy and the server mounts MCP routes. After that guard, the route-path assertion still depends on mocked server construction, so this PR also matches master by verifying register_all_routes directly.

The OpenLineage manifest change matches master; it is a placeholder value, not a real secret.

Fixes #6519.

Validation

• make -n build-ui
• python3 -m py_compile sdk/python/tests/unit/api/test_api_rest_registry_server.py sdk/python/feast/api/registry/rest/rest_registry_server.py

I could not run the full UI build locally because yarn is not installed in this shell. I also could not run the targeted Python test locally because uv is not installed in this shell, and I could not run pre-commit locally because pre-commit is not installed in this shell.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f89eb23bc4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Build the UI from the release ref

Because this target now compiles the checked-out ui/ sources, the existing wheel workflow bundles the wrong UI when checkout_ref or the computed release tag differs from the workflow's initial checkout: .github/workflows/build_wheels.yml runs make build-ui at lines 64-65, then only later does git checkout "${CHECKOUT_REF:-$VERSION}" at lines 76-78 before building the wheel. In those release/verification runs, the Python package is built from the requested ref but sdk/python/feast/ui/build was produced from the earlier ref, so published wheels can contain a frontend from the wrong branch/tag.

Useful? React with 👍 / 👎.