plugin-approvals: the ruled record-reader visibility tier (#8652) is reachable only through a constructor option no app can set — declare its opt-in where an app can #22560

Blocked-by: #22607
Unblocks: #22559

Filing gate: ③ executing a maintainer ruling that is unreachable for its consumers. Split out of #22559's second half by the triage seat (seat post #6015, session_01AavokzJ5DndAwitDXvKy4U). ⛔ Not a claim.

The ruling, and why no app can use it

• Ruling on 【能力需求】plugin-approvals 审批请求可见性:对业务记录有读权者应可只读查看审批动态(或提供可见性 hook) #8652 (5299823744, maintainer 「同意」): "A user with read access to the target business record may view that record's approval requests and full action history, read-only … Enabled by a per-object or plugin-level switch, default OFF … the downstream project opts in."
• On main, the switch is ApprovalsPluginOptions.recordReaderVisibleObjects (approval-service.ts:1235, read at :1290). It is a constructor option only.
• The CLI's serve constructs ApprovalsServicePlugin with no options, as plugin-approvals: sys_approval_request has no parent-record read gate on the data door, and the ruled record-reader tier cannot be switched on by an app (17.7.0) #22559 measured on 17.7.0 and on main 4638625. So no app metadata reaches the switch, and the ruled opt-in cannot be exercised by a config-driven app. hotclm's contract page is the measured consumer.

What to build

• A declarative opt-in that an app's own metadata carries. The ruling names it per-object or plugin-level. The per-object form (on the object's approval or visibility settings) matches how other capabilities are declared. The spec seat picks the exact key and declares it once.
  • It feeds the same recordReaderVisibleObjects set the constructor option feeds.
  • The constructor option stays for hosts that build the plugin themselves.
• Default OFF is preserved: an app that declares nothing sees no change.
• Clause-②: yes (widening). A new declarable key, on the v18 line.

Order

#22559, the data-door visibility parity, lands first or alongside. With the tier switched on, the data door and the approvals door must both honour it from one definition. Otherwise turning it on widens one door and not the other.

Acceptance

• An app declaring the opt-in for an object: a caller who can read a record of that object sees its approval requests read-only on both doors, and is offered no approval actions.
• An app declaring nothing: unchanged.
• Pins for both, plus a control: a caller who cannot read the record sees nothing.

Dedupe: search over objectstack for a declarative recordReaderVisibleObjects switch found only #22559, which this card splits.