fix(parser): handle path-level parameters when filtering - #4450

filterSpec dropped a path only when the whole path item object was
empty, so a path whose operations were all filtered out but which
still had a path-level `parameters` array survived filtering. The
parser then tried to resolve that array's $refs against components
already stripped by the filter, and threw.

Check for the presence of any HTTP method instead of the object being
completely empty.

…en filtering

filterSpec iterated every key of spec.paths without skipping `x-`
spec-extension entries, so a primitive extension value (e.g.
`{ 'x-foo': 'bar' }`) made `method in pathItem` throw. It also deleted
any path item left with no direct HTTP method keys, which incorrectly
dropped `$ref`-only path items (their operations live in the
referenced object, which filterSpec never resolves) instead of only
dropping items whose operations were actually filtered out.

Applied to 2.0.x, 3.0.x and 3.1.x, matching the `x-` skip already used
by each version's parser/index.ts.

buildResourceMetadata and filterSpec only ever looked at spec.paths,
so webhook operations were invisible to parser.filters entirely: with
orphans:false, a component only referenced by a webhook operation
looked unused and was dropped, and parseWebhooks then threw resolving
the now-missing $ref. Webhook-level `parameters` had the same
unattributed-dependency problem paths had before this PR.

Mirror the paths handling for webhooks (3.1.x-only, since 2.0.x/3.0.x
have no webhooks field):
- buildResourceMetadata collects `#/webhooks/{name}/{method}` operations
  and attributes `#/webhooks/{name}/parameters` dependencies to them.
- filterSpec (3.1.x) filters spec.webhooks the same way it filters
  spec.paths, skipping `x-` keys and preserving `$ref`-only webhooks.
- collectFiltersSetFromRegExpsOpenApiV3 matches operations.include/
  exclude regexps against webhook operations too.

Webhook operation keys reuse the existing `operation/` namespace
(webhook names can't start with `/`, so they can't collide with real
path keys), so no Filters config changes were needed.

components.pathItems is out of scope: it isn't parsed anywhere in this
codebase today, so wiring it into the filter would mean building new
parsing/IR support from scratch rather than extending an existing
filter path.

Codecov flagged the webhooks additions in the previous commit as
undercovered:
- shared/utils/filter.ts's new regex include/exclude branch for
  webhook operations in collectFiltersSetFromRegExpsOpenApiV3 was never
  exercised through the public createFilters() entry point.
- 3.1.x/parser/filter.ts's `x-` skip for spec-extension keys under
  `webhooks` (mirroring the existing paths one) had no covering case.

Verified via local coverage run that both files' new lines are now
fully hit; remaining gaps in those files are pre-existing and outside
this PR's diff.

A string extension value (the previous `'x-foo': 'bar'`) only
exercises the `x-` skip incidentally, since bracket-access property
reads on strings/numbers/booleans don't throw either way. `null` is
also a spec-legal extension value and does throw on property access,
so it actually requires the explicit `x-` skip rather than merely
tolerating a lucky operand type.

Replace the full pre-scan of every graph node with a direct pointer
lookup: the pointer to a path/webhook's `parameters` is fully derivable
from the operation's own path segment via pathToJsonPointer, so there's
no need to walk the entire graph just to find those nodes. Cache the
result per path/webhook so operations sharing a path (e.g. GET and
POST on the same route) don't recompute it per method.

Co-authored-by: Pintu Kumar <pksharmagh4@gmail.com>