Authorization coverage: what each policy gates and what is not gated #1389

Part of the epic #1387.

Scenario this serves. An application sells a plan per asset (a vessel in a fleet, a site, a workspace), not per customer. Which views, API operations and tools a caller may use depends on the plan of the specific asset they act on. Today a policy decides from the caller (role, claim) and from the arguments of the command or query. It cannot decide from state the application has recorded, such as the asset's plan.

Problem

Nothing tells a modeller which commands, queries, screens and tools are gated by which policy, or which are not gated at all. With plan-based gating spread across a product, the real risk is the surface someone forgot.

What the person should see

• For a policy: everything it gates, and the plan or entitlement it depends on.
• For an operation: its effective authorization, including what it inherits from its module and feature.
• A check that flags operations in a chosen area that have no authorization, or that read entitlement data but are not gated, in the same place the completeness check (Completeness check: find fields with no source and elements left unconnected #1365) reports unconnected elements.
• A view of a matrix of plans against gated features where the model has the data to draw one.

Done when

A reviewer can answer "what is a customer on the basic plan unable to do?" from Studio without reading the model text.

Epic: #1387.
Siblings: Cratis/Screenplay#1230, Cratis/Screenplay#1231, Cratis/Screenplay#1232, Cratis/Screenplay#1233, Cratis/Screenplay#1234, Cratis/Arc#3764, Cratis/Arc#3765, Cratis/Arc#3766, Cratis/Chronicle#5765, Cratis/Stage#1048, Cratis/Stage#1049, Cratis/Stage#1050, #1388, #1389, #1390.