FIX: Read the resource key in the failure to match example the way the others do

[jwrosewell]

Problem

cloud/failuretomatch.py read the resource key from the resource_key
environment variable alone. Every other example in this package reads it
through ExampleUtils.get_resource_key(), which looks at
_51DEGREES_RESOURCE_KEY first and falls back to the older name, and
ci/run-integration-tests.ps1 sets _51DEGREES_RESOURCE_KEY for that
reason.

So a reader who had set the current name, and could run every other cloud
example, was told by this one to create a resource key.

$ _51DEGREES_RESOURCE_KEY=<key> python cloud/failuretomatch.py

    You need to create a resource key at
    https://configure.51degrees.com?... and paste it into the code,
    'replacing !!YOUR_RESOURCE_KEY!!

Nothing caught it, because this is the one cloud example with no test.
The other five are covered by tests/test_cloudexamples.py.

What changed

• cloud/failuretomatch.py asks ExampleUtils for the key and prints
  ExampleUtils.get_missing_resource_key_message() when there is none,
  so it answers to the same variable names as the rest and names the
  variable it wanted. The link to the configurator share is kept, on one
  line, because the campaign lint reads a line at a time.
• tests/test_cloudexamples.py runs the example as a script with the
  current variable set and the older one removed, and checks that it does
  not report a missing key, that it prints its answer, and that none of
  the fault markers the other example tests look for appears.

Verification

• pytest tests/test_cloudexamples.py -k failuretomatch with a bespoke
  resource key: passes. Against the example as it was, the same test
  fails on "No resource key found".
• The example run by hand three ways with a bespoke key: with
  _51DEGREES_RESOURCE_KEY alone it answers True then False for the
  two User-Agents, with resource_key alone it does the same, and with
  neither it names the variable to set.
• pytest tests/test_cloudexamples.py with a bespoke key: 4 passed, 2
  failed. The two failures are taclookup_console and
  nativemodellookup_console, which need the hardware product that no
  test key carries, and they fail the same way on main.
• utm-lint.ps1 -Campaign device-detection-python is clean.

Outstanding

• The two hardware examples above cannot be run by anyone with the keys
  available, which is an entitlement matter rather than a code one.

Sibling change

The PHP repository has a fault in the same example, although a different
one, in
device-detection-php#74.
There the failure to match example wrote its built pipeline to a file and
reused it on the next run, so a run with one resource key answered with the
properties of whichever key had run first. Neither change depends on the
other.

CI

The "Pull Requests" workflow was dispatched on this branch with
dryrun=true. Run
35164298813
passed on all 15 build and test jobs. It ran on commit 4ae4bac5, and the
only later commit, a9c7dff0, adds one blank line between two tests, so
the head commit itself carries the UTM link lint check alone. Anyone
wanting a check on the head commit will have to dispatch the workflow
again.

Still to do elsewhere

readme.md and fiftyone_devicedetection_examples/readme.md still tell a
reader to set resource_key, which is the older name. Both stay correct,
because ExampleUtils reads that name as a fallback, but they do not name
_51DEGREES_RESOURCE_KEY at all. That is a separate piece of work and is
not touched here.

Taken out of draft on 17 September 2026

The paragraph above asking for a run on the head commit has now been done.
Run 35190436789
is on the head commit a9c7dff, a dispatch of the Pull Requests workflow
with dryrun set, and all 19 jobs passed. The job logs show the example
suites running rather than being skipped, at 5 passed with 8 skipped, then
51 passed, then 14 passed, then 19 passed, and the Selenium contract tests
reporting Failed: 0, Passed: 9.

The branch is level with main, so nothing needed merging in.

Still outstanding, and it does not stop this merging. The two hardware
examples named above cannot be run with any key CI has, which is an
entitlement matter rather than a code one, and they fail the same way on
main.

[jwrosewell]

Proven in CI

Full build and test run on this branch: https://github.com/51Degrees/device-detection-python/actions/runs/35190436789

A draft pull request only runs the link lint, so the Pull Requests workflow was dispatched against this branch as a dry run to get real evidence. Nothing was merged, and the log shows why: with no pull request based on this branch the run builds the branch on its own as pull request 0, and the checkout and completion steps both print "Not running for a PR".

All 19 jobs finished green, being 15 build and test jobs (Python 3.10, 3.11, 3.12, 3.13 and 3.14 on Ubuntu, Windows and macOS), the pull request lookup, the configure step, the performance comparison and the completion step.

Reading the job logs rather than the conclusions, each of the 15 build and test jobs reports 89 tests passed, the same on every platform and every version, and no failures. Searching the whole log for "Failed!", "FAILURES" and a non-zero failed count finds nothing.

The pull request has not been marked ready and no review has been requested.