Require ai_disclosure 1.0.0-alpha2, the first release carrying ai_disclosure.grade_lookup

Committed as 195e390, pushed to both main and 1.0.x.

What landed:

• composer.json — drupal/ai_disclosure from ^1.0@alpha to ^1.0.0-alpha2.
• README.md — the install instructions name the new floor, and say why it is alpha2 rather than any alpha. The measured minimum-stability error message quoted there still names alpha1, with a note that the version in that message is whichever alpha is current; it was not silently edited to say alpha2, because that output has not been re-measured.
• The recorder spy in the kernel suite implements attestHumanReview(), which alpha2 added to DisclosureRecorderInterface.
• The equivalence test's skip message no longer claims the constraint resolves to alpha1, since it cannot any more.

Verified before the push: phpcs clean, phpstan clean, 96 tests and 211 assertions with none skipped, and the traceability check reporting nothing unresolved across seven specs. CI pipelines 958543 (main) and 958544 (1.0.x) were still running when this was written; job statuses rather than the pipeline status are the thing to read there, since two jobs in the shared template are allowed to fail and leave a pipeline green.

Marking fixed.

Correction to the comment above: marking this fixed while the pipelines were still running was premature, and the phpstan job went red on job 12154818. It is green now, in cddd954, and the cause is worth recording because it is a consequence of the alpha2 bump rather than a separate problem.

Nothing in the code was wrong. phpstan.neon.dist carried two ignoreErrors entries for ContentCredentialsServiceProvider — booleanNot.alwaysTrue and deadCode.unreachable — and they failed by being unmatched, not by matching something new.

They exist because phpstan-drupal builds its service map from the services.yml files it can see. Analysed standalone, with no Drupal root, that is this module's own file alone, so asking the container whether it has ai_disclosure.grade_lookup folds to a constant false, the negation reads as always true, and the swap below it reads as dead code. On drupal.org's CI the module sits inside a site, every installed module's services.yml is read — and alpha2 is the first release whose file declares that service. So the two errors stopped being reported there, reportUnmatchedIgnoredErrors did what it is for, and the job failed.

The entries were written to be self-expiring: the comment beside them said that the day the analysis could see the service, the run would fail until they were deleted. That day arrived and deleting them turned out to be the wrong answer, because the two environments now disagree about the same code — deleted ignores are red standalone, strict ignores are red on CI. Both now carry reportUnmatched: false, which the loadIncludes.moduleNotFound entry below them already had for the same underlying reason: the error is an artefact of analysing without a Drupal root.

The cost is written into the file rather than glossed over — those two ignores no longer expire on their own, so if that swap ever does become genuinely dead code, the configuration will not say so.

Pipelines 958568 (main) and 958569 (1.0.x) are green on every job, checked per job rather than by pipeline status, including the two the shared template allows to fail. Leaving this fixed.

One thing a local run could not have caught: phpstan was clean here both before and after the fix. The disagreement only exists where there is a Drupal root.

@sjpagan Thanks for looking at this so carefully, and for offering. Yes, I'd really like that. An interface with a 1.x promise is a lot nicer to build on than my method_exists() check.

One small thing before you freeze it: could the interface docblock also spell out the behaviour, not just the signatures? What my adapter actually relies on is in your current docblock. Results are keyed by grade ID in both formats, the URI match is exact, an empty URI just returns [], and the order is for stability rather than a ranking. If those stay part of the promise, that's everything I need. I don't use getCacheTags() and I don't touch GradeLookupFormat, so I have no wishes there.

Nothing needs to change on my side until it's in a release, since the current check keeps working as long as the method is there. Once it ships, I'll bump the requirement, type-hint the interface and swap the check for an instanceof test.

I'll probably keep the stand-in on my own small interface rather than have it implement yours. It's only there for the case where someone swaps in their own version of the service, and implementing the full interface there wouldn't add much.

Would you mind opening an issue for it in the ai_disclosure queue? I'll follow along there. Thanks again!