enhancement(cli): #1769 warn on unsupported top level greenwood config options

[jstockdi]

Related Issue

Resolves #1769

Documentation

No documentation changes. The set of supported options is already documented at Configuration and is unchanged by this PR.

Summary of Changes

An unsupported top level key in greenwood.config.js is currently dropped without any diagnostic. The user config is destructured into a fixed list of names in readAndMergeConfig, and the merged config is built only from those bindings, so anything else is silently discarded. A near miss typo of a real option (basepath for basePath) is indistinguishable from an option simply not working.

This adds a check right after that destructure which warns once per unrecognized top level key:

Configuration warning: "basepath" is not a supported configuration option and will be ignored.

It warns, it does not throw. Rejecting an unknown key would be a breaking change: any project that currently carries a stray or forward compatible key builds fine today and would start failing. That call belongs to you, not to this fix, so this only makes the discard visible. It follows the existing non-fatal precedent in this same file, the "more than one custom renderer plugin detected" warning.

Scope is deliberately top level only. Unknown keys nested inside devServer and polyfills are dropped the same way, but those sub-objects are looser (devServer.proxy is already an unvalidated pass through bag), so warning there has a higher chance of false positives. Happy to extend to the nested scopes in a follow up if you want it.

The list of supported options is derived from defaultConfig rather than being a second hand maintained list, so it stays in sync automatically. staticRouter is appended because it is the one supported option with no default value.

Testing

New test case packages/cli/test/cases/build.config.unknown-keys. It builds with a config containing a misspelled real option (basepath), a wholly unknown option (notARealOption), and a supported option (staticRouter), then asserts warnings for the first two and no warning for the third, while the build still succeeds. On master the two warning assertions fail; with this change all pass.

I did not fold this into an existing config case because none of them exercise a successful build with unsupported keys, and the point of the test is that the build still exits cleanly. Folding it into one of the build.config.error-* cases would not have covered the "warn, do not throw" behavior.

Overlap with #1746

#1746 (approved, unmerged) also touches packages/cli/src/lifecycles/config.js, swapping forEach for for...of in the plugins loop at lines 156-181. This change sits at lines 78-80 and 122-130, so the hunks do not collide and the two should merge in either order.

[thescientist13]

staticRouter has no default value of its own

hmm...this just seems like an oversight? It's documented
https://greenwoodjs.dev/docs/reference/configuration/#static-router

and captured in the type definition
https://github.com/ProjectEvergreen/greenwood/blob/master/packages/cli/src/types/config.d.ts#L26

Seems like we should just add staticRouter: false to the defaultConfig?

[thescientist13]

Opted to classify this as an enhancement instead of fix, fyi (as I don't really consider anything to be broken here, this is just a nice bit of feedback for users)