Add module-aware template resolution to prevent false update banners

[SaravanakumarR2018]

Motivation

• Duplicate component definitions across backend modules caused frontend template lookups by name to collide and produced false “Update available” banners. The goal is a universal, module-aware lookup so templates resolve by metadata.module when present.

Description

• Add a new utility src/frontend/src/utils/component-template-utils.ts exposing buildTemplatesByModule to build a module->template map and resolveTemplateEntry to prefer a module-match when resolving templates.
• Wire the module map into the types store by adding templatesByModule to the TypesStoreType, initializing it in useTypesStore, and generating it in setTypes using buildTemplatesByModule.
• Update the update-check path to use module-aware resolution by calling resolveTemplateEntry from check-code-validity and by passing templatesByModule into checkCodeValidity from flowStore.
• Keep existing file modifications minimal and add only one new file; update unit tests to mock and assert the new module-template behavior.

Testing

• No automated test suites were executed as part of this change; only unit test files were updated (src/frontend/src/stores/__tests__/typesStore.test.ts and src/frontend/src/stores/__tests__/flowStore.test.ts) to mock buildTemplatesByModule and to assert templatesByModule is produced and consumed.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e3ceca9371

ℹ️ 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]

Keep per-module mappings from colliding

The new module map only retains the first component for each metadata.module, so any additional components in the same module will be resolved to the wrong template. The repository already ships component metadata where many components share a module (e.g. src/lfx/src/lfx/_assets/component_index.json reports far fewer modules than components), so resolveTemplateEntry will return a mismatched template for most components in those modules. That will make checkCodeValidity compare a node’s code/outputs against the wrong template, producing false “update available” banners or missing real updates for those components. Consider keying by {module, type} or storing a module→type map rather than a single component per module.

Useful? React with 👍 / 👎.