packaging/bundle-validation has no hudi-presto-bundle coverage

## Task Description

**What needs to be done:**

Add `hudi-presto-bundle` coverage to `packaging/bundle-validation`, exercised in a way that resolves its bundle dependencies from the repository rather than from the reactor.

**Why this task is needed:**

#19433 fixed a regression where `hudi-presto-bundle` silently shipped a jar containing **0** `org/apache/hudi/hadoop/**` entries instead of 109, losing `HoodieParquetInputFormat` -- the class the bundle exists to provide. Shade does not fail when an `artifactSet` include matches nothing, so the build stayed green and the jar just got quietly smaller.

Nothing in CI could have caught that, for two independent reasons.

**1. There is no presto coverage at all.** `git grep -il presto packaging/bundle-validation` returns nothing, and the same is true for `trino`. `validate.sh` exercises `hudi-cli-bundle`, `hudi-kafka-connect-bundle`, `hudi-metaserver-server-bundle`, `hudi-utilities-bundle` and the spark/flink bundles. Of the seven bundles touched by #19433, only `hudi-hadoop-mr-bundle` appears in `bundle-validation` at all -- `hudi-presto-bundle`, `hudi-aws-bundle`, `hudi-gcp-bundle`, `hudi-datahub-sync-bundle` and `hudi-hive-sync-bundle` have no stage. (The `azure` matches under that directory are the Azure Pipelines config, not `hudi-azure-bundle`.)

**2. Even with a stage, `-am` would hide this class of bug.** Every `-pl packaging/...` invocation under `.github/workflows` and `scripts/` passes `-am` -- 10 out of 10 on master. With `-am` the dependency bundles are built in-reactor, and Maven's `ReactorReader` serves the effective model rather than the published dependency-reduced POM, so the resolution path that actually broke is never exercised. A stale un-reduced POM in `~/.m2` masks it the same way.

Suggested minimum: a validation step asserting the presto bundle contains `org/apache/hudi/hadoop/HoodieParquetInputFormat.class`, built **without** `-am` so `hudi-hadoop-mr-bundle` resolves from the repository. A jar-entry count assertion would also have caught this specific regression, since the count went 109 -> 0.

Worth considering more generally: a check that fails the build when a shade `artifactSet` include matches no artifact would catch this whole class of silent shrinkage across all 16 bundles, rather than one bundle at a time.

## Task Type

Test enhancement

## Related Issues

**Parent feature issue:** #16407
**Related issues:** #19433, #19466