Fix embedded wildcard validation in cpeName searches

[afoote-mitre]

Summary

Fixes POST /search accepting embedded wildcards in required cpeName components even though this filter expects a concrete asset name.

Review scope: 7 files, 126 additions and 43 deletions. Of the 169 changed lines, 18 are runtime logic, 127 are regression tests, and 24 are documentation or generated OpenAPI. The only runtime change is in utils/cpe.js.

Why These Changes Were Needed

Production accepted inputs such as 2.6.* and 10.* as concrete cpeName versions. Range comparison discarded their wildcard characters, so these searches behaved like versions 2.6 and 10 rather than version-family searches. This produced successful responses with unexpectedly narrow or broad result sets.

Change	Primary files	Why it was needed
Reject unescaped * and ? anywhere in the required cpeName components, using the existing HTTP 400 INVALID_CPE_NAME response. Recognize escaped literal characters without accepting a wildcard after an escaped backslash.	utils/cpe.js	The previous validation rejected only a whole-component *, allowing unsupported patterns to reach semantic version comparison.
Cover reported version patterns, wildcard vendor/product values, escaped literals, backslash parity, and rejection before range comparison.	utils/cpe.test.js	Prevent the original parsing defect and escape-handling regressions while preserving valid concrete inputs.
Verify wildcard versions return HTTP 400 before the controller runs, while concrete versions, standalone -, escaped literals, and existing punctuation handling remain accepted.	routes/cpeName.test.js	Ensure the parser restriction is enforced at the public endpoint without rejecting previously supported non-wildcard inputs.
Explain concrete-name searches, explicit version intervals, hypothetical versions matching stored ranges, and the distinction between NA and an unrestricted version. Add a Linux 2.6 inclusive to 2.7 exclusive example.	README.md, routes/swagger.js, api-docs/openapi.json	Help callers distinguish invalid wildcard inputs from legitimate matches against broad or open-ended source criteria.
Assert the documented wildcard restriction, escaped-literal handling, range guidance, and NA meaning.	api-docs/openapi.test.js	Keep the generated public documentation aligned with the validation behavior.

Compatibility and Scope

• Callers using embedded wildcard patterns in required cpeName components will now receive HTTP 400 instead of misleading successful results.
• For a version interval, use virtualMatchString without a version component and provide explicit version boundaries. For all versions, use virtualMatchString with an omitted version or a whole-component *.
• isVulnerable retains its current name and behavior.
• Standalone - remains the supported CPE NA value, with its existing range-matching policy.
• Optional-component wildcards, version comparison, candidate limits, pagination, virtualMatchString behavior, and /webSearch are unchanged.
• This change does not implement PIT or alter production configuration.