## Description `ai_content_review` was built around reviewing Drupal content, and the assumption reached every layer. Routes named an entity type and id, controllers loaded a content entity, the orchestrator's entry point took an `EntityInterface`, and `ReviewRule` matched on entity type plus bundle. The `external` bundle of `review_record` existed with its `url` field and its read-side display, and nothing could create one, because nothing above the storage layer could describe a subject that was not an entity. This makes the whole path subject-driven. A `review_record` bundle plugin answers everything about what it reviews: how to name it, how to reach it again from a key, who may see it, which rules apply, how a suggestion is written back, and whether it has changed since a review. Every layer above asks the plugin instead of assuming. ## Tasks ### Record type contract * [ ] `subjectKey()` and `subjectKeyOf()`, so a subject can be named in a URL and a record can be matched back to it. Internal uses `entity_type.entity_id`, external base64url so a URL survives one path segment. * [ ] `subjectFromKey()`, the inverse, so a request naming a subject can resolve it. * [x] `subjectAccess($subject, $account, $operation)`, so controllers stop calling `$entity->access()` directly. * [x] `subjectConditions()` and `subjectIdentityConditions()`, splitting "this subject in this exact state" from "this subject in any state". * [x] `rulesFor()`, `applySuggestion()`, `subjectChangedSince()`, moving the last three entity-specific decisions out of callers. ### Rule config * [x] `record_type` on `review_rule`, with `entity_type` and `bundles` demoted to internal-only qualifiers. * [x] Config schema updated. The existing key is `ai_content_review.rule.*`, not `review_rule.*`. * [x] `ai_content_review_update_10002()` stamping `record_type: internal` on existing rules. Normalisation, not a fix: `ReviewRule::$record_type` defaults to `internal`, so an unstamped rule already reads correctly. What the hook buys is config that states what it targets instead of relying on a PHP default, and no export drift the first time an old rule is saved through the form. * [x] `ReviewRuleForm` gained a record type selector; entity type and subtype are stated to be internal-only. * [x] `ReviewRuleInterface` narrowed to `getCriteria()` and `getRecordTypeId()`. The entity type and bundle methods moved to a new `InternalReviewRuleInterface`, so a second kind of rule can exist without returning an empty entity type and empty bundle list to satisfy a contract it cannot honour. ### Request layer * [x] `{entity_type}/{entity_id}` replaced with `{record_type}/{subject_key}` across all 10 routes and 11 controller methods. * [x] Both private `loadEntity()` helpers deleted; resolution goes through `resolveSubject()` and the plugin. * [x] URL-building call sites updated, and `js/review_run.js` no longer concatenates the apply URL: it is built server-side as `apply_url` next to the existing `decide_url`. * [x] `runForEntity()` is `runForSubject(mixed $subject, ...)`. * [x] Read side: `loadLatestForSubject()`, `loadLatestForSubjects()`, `loadLatestForCriterion()`, and `ReviewSummaryBuilder::build(mixed $subject, ...)`. ## Adding a record type A `review_record` bundle plugin is the whole extension point. Implement 13 methods on `ReviewRecordTypeInterface` and add one line to `ReviewRecordBundleClasses` mapping the bundle to its entity class: * Identity: `supports()`, `subjectKey()`, `subjectKeyOf()`, `subjectFromKey()`. The key goes in a URL path segment and must round-trip, so it has to be identity-based and path-safe. Internal uses `entity_type.entity_id`; external base64url-encodes the URL. * Storage: `subjectValues()`, `subjectConditions()`, `subjectIdentityConditions()`. The last two are separate on purpose: exact state for run lookup and the duplicate guard, any state for history. * Behaviour: `subjectAccess()`, `rulesFor()`, `applySuggestion()`, `subjectChangedSince()`, `buildReviewContext()`, `getTokenContexts()`. Everything above then works with no further change: all 10 run routes, the orchestrator, the record loader, the batch read, and the history list. ## Supporting external reviews More is already in place than the `external` bundle suggests. * A `ReviewRule` can target it. `record_type` accepts any record type plugin id, `ReviewRuleForm` offers them all, and `ExternalReviewRecordType::rulesFor()` returns `loadForRecordType('external')`. Entity type and bundles are simply ignored for it. * `runForSubject($url)` matches those rules and produces a completed `external` record with the URL stored. Covered by `ExternalReviewTest`. * The run, poll, status, pause and heartbeat routes all accept `external` plus a subject key. * Apply is refused, not broken: `subjectAccess($url, $account, 'update')` is forbidden and `applySuggestion()` throws, so nothing has to test for a bundle to hide the button. ## Acceptance criteria * [x] `ReviewOrchestrator` has no method taking an `EntityInterface`. * [x] No route names `entity_type` or `entity_id`; `loadEntity()` exists nowhere in the module. * [x] A URL runs end to end through the same entry point an entity uses and produces an `external` record. * [x] Existing internal rules keep matching exactly as before, and a rule with no `record_type` is treated as internal. * [x] Updating an existing site does not drop or disable any configured rule. ## Testing instructions *(added by implementor before review)* 1. ## Related issues *(optional)* <!-- /relate #3585810 -->