FIX: Bump device-detection-cxx and align tests to unified result shape

[oleksandrlazarenko-pi]

Relates to #TASK

Picks up the device-detection-cxx change that unified the detection result
shape (51Degrees/device-detection-cxx#362, merged in
51Degrees/device-detection-cxx#385) and updates the two test assertions that
encoded the removed fast path.

The submodule bump and the test updates have to land together: the new
assertions do not hold against the previous native library, and the old ones do
not hold against the new one.

Why the nightly failed

The nightly on #558 reported 3 failures out of 33 in
51Degrees :: Device Detection :: Hash :: On Premise
(run):

ValueHashTests.Values_Hash_MatchedUserAgents:159   expected:<1> but was:<4>
TestProcessTests.Process_Hash_CaseInsensitiveKeys:67  validKeys vs userAgents size mismatch expected:<1> but was:<4>
TestProcessTests.Process_Hash_EmptyUserAgent:52       validKeys vs userAgents size mismatch expected:<1> but was:<4>

Both assertions tied the result shape to evidence cardinality, which is exactly
the coupling #362 removed:

• DataValidatorHash counted the accepted evidence keys and asserted one
  matched User-Agent per key.
• ValueTests.matchedUserAgents asserted exactly one.

Detection now produces one result per component the engine populates, so a
single User-Agent yields 4 rather than 1. These are the intended consequence of
the native change, not new defects.

Changes

• Bump device-detection-cxx to c7b2822 (includes Update submodules #362 / Update properties #385).
• DataValidatorHash — replace the per-evidence-key equality with a bound (no
  more matched User-Agents than components the engine populates) plus "valid
  evidence yields at least one result".
• ValueTests.matchedUserAgents (shared test helpers) — same bound. The
  per-entry check that every matched substring really occurs at the expected
  offset in the original User-Agent is untouched; that is the substantive
  assertion.

The counts are deliberately asserted as a bound rather than a fixed number: the
exact value is "components that have available properties", which depends on the
data file. Pinning a literal would make the tests brittle across data file
revisions. This also brings the on-premise helper into line with the cloud
ValueTests.matchedUserAgents, which already asserts a range rather than an
exact count.

Only the on-premise path is affected — ValueCloudTests imports the cloud
module's own ValueTests, which is unchanged.

Verification

Built the native engine against the new submodule and ran the tests on Windows
x64 (JDK 17):

• device-detection.hash.engine.on-premise: 33 tests, 0 failures (was 3
  failures)
• device-detection.shared: 3 tests, 0 failures

Behaviour change to be aware of

#362 is an observable change for on-premise consumers, and this PR is where it
reaches Java:

• The number of entries in getUserAgents() (and match metrics derived from the
  result list) is now determined by the data file's components, not by how many
  evidence pairs were supplied. Redundant evidence no longer changes it.
• With allowUnmatched enabled, components with no matched profile are filled
  with each component's default profile, matching evidence-based processing.

Please call these out in the release notes. The same change is landing in
device-detection-dotnet, and the other on-premise language bindings will need
the equivalent test updates as their submodule PRs land.

Supersedes

Replaces the automated submodule PR #558, which cannot go green on its own
because it carries the bump without the matching test updates. Close #558 when
this merges.