chainlink Add chain selector validation for configured chains

Problem Currently, if a chain is configured in TOML with a ChainID that doesn't have a corresponding ChainSelector in the chain-selectors library, the Chainlink node boots up without issues but can experience silent failures in the CCIP plugin which boots up (and reloads) asynchronously. When the CCIP plugin fails, it essentially kills the entire CCIP network silently. This wasn't a big issue in the past since our workflows always required bumping the CS version in the Chainlink go.mod but it became more problematic since the introduction of extra-selectors which allows adding new selectors at runtime bypassing CS version bumps.

Solution This change implements fail-fast chain-selector<>chain config validation in application.go that runs before any jobs or services start, and fails (crashes) the node at startup with a clear error message if any chain has an invalid ChainID → ChainSelector mapping,

The impact is minimal as the node will fail to boot if it has invalid config but it will not affect any further plugins downstream.

Nov 11 '25 05:11 HelloKashif

:wave: HelloKashif, thanks for creating this pull request!

To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team.

Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks!

Nov 11 '25 05:11 github-actions[bot]

I see you updated files related to core. Please run pnpm changeset in the root directory to add a changeset as well as in the text include at least one of the following tags:

#added For any new functionality added.
#breaking_change For any functionality that requires manual action for the node to boot.
#bugfix For bug fixes.
#changed For any change to the existing functionality.
#db_update For any feature that introduces updates to database schema.
#deprecation_notice For any upcoming deprecation functionality.
#internal For changesets that need to be excluded from the final changelog.
#nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
#removed For any functionality/config that is removed.
#updated For any functionality that is updated.
#wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.