Add a database ID credential so the reco counts tests can be verified

[adamtheturtle]

Follow-up to #3343 and #3357.

Blocked by VWS-Python/vws-web-tools#1446, which has to expose the database ID before the credential can be generated here.

#3343 asked for verified fake tests covering a valid reco counts request, an out-of-range month and a malformed month. Those tests are currently mock-only, so that acceptance criterion is not met.

Why they are mock-only

POST /imagetargets/databases/{database_id}/reports/recoCounts names a database ID in its path. The test credentials contain no database ID, so tests/mock_vws/test_reco_counts_report.py sends a random one:

database_id = uuid.uuid4().hex
request_path = f"/imagetargets/databases/{database_id}/reports/recoCounts"

Against real Vuforia this returns 401, even though the request is correctly signed with the working database's server keys. Real Vuforia appears to require the path's database ID to belong to the credentials, and it rejects the request before it looks at the month, so the valid, out-of-range and malformed cases all fail identically. The tests were moved to mock_only_vuforia in #3357 to unblock CI, and differences-to-vws.rst records that nothing about the endpoint is verified.

This is the only Cloud Targets endpoint whose path identifies a database by ID rather than by target ID or not at all, which is why the gap has not come up before.

What is needed

The database ID has to reach the tests as a new credential, something like VUFORIA_DATABASE_ID:

1. vws-web-tools must expose it, tracked in Expose the database ID in get_database_details vws-web-tools#1446. get_database_details returns only database_name and the four access keys, and the ID is not scraped today. Where the target manager exposes it has not been confirmed; the likely candidates are the URL of the database page and the "Database Access Keys" tab. Everything below is blocked on that issue.
2. admin/create_secrets_files.py writes each secrets file from DatabaseDict, so _generate_secrets_file_content needs a VUFORIA_DATABASE_ID= line.
3. vuforia_secrets.env.example needs the new key, since the non-credentialed CI jobs copy it verbatim.
4. _CloudDatabaseSettings in tests/mock_vws/fixtures/credentials.py needs a database_id field, plumbed through to whatever the reco counts test helper reads.
5. The 100 encrypted secrets files must be regenerated. CI copies ci_secrets/vuforia_secrets_${JOB_INDEX}.env for each parallel job, and none of them have the key. Either make the field optional and skip the real-Vuforia tests when it is absent, or regenerate and re-encrypt secrets.tar.gpg in the same change — a required field against stale secrets would break every credentialed CI job, not just this test.
6. Switch TestRecoCountsReport back to verify_mock_vuforia and remove the mock-only note from differences-to-vws.rst.

What this would tell us

Beyond restoring the acceptance criterion, running these against real Vuforia is the only way to check the guesses made in #3357, all currently documented as unverified:

• whether a malformed month and an out-of-range month both return Fail with a 400, which the documentation does not specify for this endpoint;
• the response headers of the report request;
• the shape of the presigned_url value: its host, path and query parameters. Real Vuforia returns a cloud storage URL, which normally carries X-Amz-* query parameters, where the mock returns a URL served by itself with none;
• whether the 401 really is caused by the database ID mismatch, rather than something else about the request.

What comes back from that URL — the CSV, the download response headers and the 404-until-ready behaviour — cannot be verified here, because a real report takes up to an hour to generate. That is #3360.

It would also unblock #3362, which proposes giving mock_vws.database.CloudDatabase a database ID so that the mock can reject a mismatched one as real Vuforia does. That change is deliberately blocked on this issue: it should not be built on the assumption that the 401 came from the database ID until a real run has confirmed it.

Acceptance criteria

• The database ID is available to the tests as a credential, and the secrets files and their example contain it.
• TestRecoCountsReport runs under verify_mock_vuforia and passes against real Vuforia.
• The behaviours listed above are either confirmed and the mock left as is, or corrected in the mock, with differences-to-vws.rst updated to drop the claims that are no longer unverified.
• A decision is recorded on whether the mock should validate the database ID in the path.

[adamtheturtle]

Probed against real Vuforia on 2026-08-08 using a throwaway database created for the purpose, so the guesses this issue was meant to settle are now settled.

The 401 is caused by the database ID. A correctly signed request naming a database ID which does not belong to the server keys returns:

401 {"result_code":"AuthenticationFailure","transaction_id":"..."}

That holds both for a random ID and for the database name passed where the ID belongs, which is the mistake a caller is most likely to make. This unblocks #3362, and confirms AuthenticationFailureError is the right result code for the mock to use.

Every month guess in #3357 was correct. All of these return 400 with {"result_code":"Fail","transaction_id":"..."}, exactly as the mock does: two months ago, next month, "2020", "2020-1", "January", "2020-01-01", and the non-string 202001.

The success response matches, other than the presigned_url value: {"result_code":"Success","transaction_id":..., "presigned_url":...} with a 200. Response headers match the mock's except x-aws-region, now #3365.

The URL shape does not match, now #3364.

Two mock bugs found in the download, now #3363.

What is still blocked here is only the test credentials. The 100 files in secrets.tar.gpg name databases such as my-database-2026-02-20-14-38-05, whose server keys still authenticate against the VWS API, but which do not appear in the target manager of the account that was used for this probe. A UI search finds nothing for them while finding other databases on that account correctly, including one which sorts last alphabetically, so the search covers the whole list rather than one page. Their IDs cannot be looked up from that account, so VUFORIA_DATABASE_ID cannot be backfilled and the real-Vuforia tests still skip.