feat(cv_backend): expose new descriptors and filterMatches in the jsfeatNext adapter

[kalwalt]

Summary

Wire the new descriptors and the GMS filter into the jsfeatNext CvBackend
adapter: declare them in capabilities, honour DescribeOptions.kind, and
expose filterMatches.

This is the issue that closes the loop between the contract amendments (#128,
#129) and the algorithm modules.

Why

#128 and #129 amend the contract; the algorithm issues add the modules. Neither
makes the new capabilities reachable through CvBackend — that is this issue.

It is kept separate rather than folded into each module issue for one reason:
cv_backend.ts does not exist yet. #96 is still a draft in its issue body. If
every module issue had to wire its own adapter, every module would be blocked on
#96 — the largest and least-started piece of work in the group. Keeping
integration separate lets the modules land while the contract implementation
proceeds on its own timeline.

Scope

• capabilities reports the detectors, descriptors and match filters this
  backend actually implements, updated as each module lands.
• describe() honours the requested DescriptorKind, dispatching to the
  corresponding module.
• Descriptors.kind and Descriptors.norm populated on every return.
• filterMatches implemented over the GMS module, and advertised through
  capabilities.matchFilters.
• Requesting an unsupported kind throws, with a typed error naming the
  requested kind and the supported set. It does not fall back to ORB: choosing a
  fallback is the high-level layer's decision, made against capabilities, and
  a silent fallback recreates exactly the bug feat(cv_backend): descriptor selection & capability declaration #128 exists to prevent.
• match() rejects descriptor sets whose kind or norm disagree.

Acceptance criteria

• capabilities accurately reflects the modules present at the time of
  merge, and a test fails if a declared capability is not actually callable.
• describe(img, kps, { kind }) dispatches correctly for every declared
  descriptor, and throws for every undeclared one.
• filterMatches runs GMS and is reachable only when advertised.
• A test with a reduced-capability backend shows the caller resolving to a
  deterministic fallback from its own preference list, with the backend
  never guessing.
• match() throws on a kind or norm mismatch.
• No new any (Replace remaining any usages with shared types/interfaces (TypedArray, MotionKernel, …) #85).

Out of scope

• Implementing the contract itself — that is Define a minimum CvBackend interface (pluggable, stateless CV contract for a high-level WebAR layer) #96.
• The PureCV, WebARKitLib and jsartoolkitNFT adapters.
• Any algorithm implementation.
• The high-level AR layer's fallback policy — only the test demonstrating it.

Dependencies

• Define a minimum CvBackend interface (pluggable, stateless CV contract for a high-level WebAR layer) #96 (contract implemented), feat(cv_backend): descriptor selection & capability declaration #128, feat(cv_backend): optional filterMatches step (GMS seam) #129.
• At least one of feat(gms): grid-based motion statistics match filter #134 (GMS) / feat(teblid): TEBLID binary descriptor module (p256, then p512) #135 (TEBLID) / Add FREAK binary descriptor module #80 (FREAK); ideally all three, but the
  adapter can be extended incrementally as each lands.

Related

• Contract: Define a minimum CvBackend interface (pluggable, stateless CV contract for a high-level WebAR layer) #96, amended by feat(cv_backend): descriptor selection & capability declaration #128 and feat(cv_backend): optional filterMatches step (GMS seam) #129
• Consumer: [Roadmap] WebAR on jsfeatNext: two-layer architecture & high-level feature set #97
• Cross-repo: the PureCV CvBackend adapter consumes this same contract and
  should reference it rather than redefining it
• Plan: docs/features2d-expansion-plan.md