fix: Invalid discoveryHandlerId can persist broken discovery upstream rows

[hengyuss]

Invalid discoveryHandlerId can persist broken discovery upstream rows
Fixes: #6466

Make sure that:

• You have read the contribution guidelines.
• You submit test cases (unit or integration tests) that back your changes.
• Your local test passed ./mvnw clean install -Dmaven.javadoc.skip=true.

[Aias00]

Reviewed #6530. The fix correctly closes the reported path in #6466 (POST /discovery-upstream with a non-existent discoveryHandlerId → orphan row + NPE in fetchAll). It reuses the existing @Existed/DiscoveryHandlerMapper.existed validator the repo already uses for the id and namespaceId fields and for the PUT path variable, so it's consistent and correct for the HTTP create/update paths. No blocker from me.

Two non-blocking items:

1. No regression test (should_fix). Issue #6466 ships a 4-step repro and the PR adds no test. The H2 discovery_handler table (schema.sql:1249), AbstractSpringIntegrationTest (@ActiveProfiles("h2")), and DiscoveryUpstreamMapperTest.existed() already provide the harness. Please add a controller/validation test that POSTs a DiscoveryUpstreamDTO with a non-existent discoveryHandlerId and asserts a 400 (plus a happy-path 200 with an existing handler) — otherwise a future revert/refactor of this annotation regresses silently. The PR checklist also leaves "submit test cases" unchecked.

2. Update endpoint behavior (nit). PUT /discovery-upstream/{discoveryHandlerId} now @Existed-validates the discoveryHandlerId inside each body element, but DiscoveryUpstreamServiceImpl.updateBatch (:115) overwrites it with the path id and ignores the body value. If the admin frontend sends a placeholder/mismatched id in the PUT body, this becomes a new 400. Please confirm the frontend sends the matching path id in each body element; if so, no action needed.

Out of scope (follow-up, not for this PR): the import/programmatic paths (DiscoveryUpstreamServiceImpl.importData at :255/:293, nativeCreateOrUpdate at :123, fed by Gson in ConfigsServiceImpl:440 and DiscoveryUpstreamDataConfigsExportImportHandler:59) bypass @Valid and can still insert orphan rows. They don't call fetchAll, so they dodge the NPE in #6466 — hence not blocking here — but a service-level existence check would fully match the issue title's intent.

[Aias00]

Clean defensive fix — adding @Existed(provider = DiscoveryHandlerMapper.class) on discoveryHandlerId rejects invalid handler ids at the validation boundary instead of persisting broken rows (the #6466 root cause). Two things worth confirming:

Is the validation actually exercised on every write path that can persist a DiscoveryUpstreamDTO? @Existed is a bean-validation annotation, so it only fires when the DTO passes through a @Valid controller method (or a programmatic Validator call). The config-import path in DiscoveryUpstreamServiceImpl.importData(...) takes DTOs and inserts them directly — if that path doesn't go through bean validation, the annotation won't catch broken imports there, and the getOrDefault(id, id) guard from #6532 remains the only protection on that flow. Worth a note on which paths are covered.

No test (the body's "submit test cases" checkbox is unchecked). A test passing a non-existent discoveryHandlerId through a @Valid endpoint and asserting a validation failure would pin the behavior.