remove filterErrors once specerrors exposes a filter helper

## Problem

`internal/validation/validation.go` contains a private `filterErrors` helper that composes
primitives already owned by `specerrors` (`LoadConfigFilter`, `NewFilter`, `Filter.Run`) to apply
`validation.yml` suppression rules to a set of validation errors.

The same pattern appears duplicated in `package-spec`'s own tests, which confirms this logic
belongs upstream — not in every consumer.

A TODO comment in the code already acknowledges this:

```
// TODO: follow-up issue — move this logic into specerrors as an exported function so consumers don't reimplement it.
```

## What needs to happen

Once `package-spec` exports a helper that encapsulates this suppression pattern, the `filterErrors`
function in this repo should be removed and its call sites updated to use the upstream API.

The `package-spec` dependency should be bumped accordingly.

## Why

Keeping this logic in `specerrors` means future consumers get correct edge-case handling for free.
`elastic-package` should not own code that is purely a composition of upstream primitives.

Start in internal/validation/validation.go at the private filterErrors helper and its call sites, then review the duplicated pattern in package-spec tests and the TODO comment. Confirm the package-spec exported helper and required dependency version before replacing the local usage. Done means the local helper is removed, call sites use the upstream API, and the package-spec dependency is bumped.

Written by the indexing model from the issue text.