CustodyPolicy::ownsDefinition and ownsSubscription are keyed on a name, so they answer for the wrong record

src/Policies/CustodyPolicy.php:23-26 and :28-31 ask whether the given tenant has a row of that name. They do not ask whether the row the caller is holding belongs to that tenant.

public static function ownsDefinition(string $tenantId, string $name): bool
{
    return $tenantId !== '' && MetricDefinition::query()->where('tenant_id', $tenantId)->where('name', $name)->exists();
}

The unique key is (tenant_id, name), so a name is unique within a merchant and two merchants may both hold net-revenue. A caller that has loaded tenant B's definition and asks ownsDefinition('tenant-a', 'net-revenue') gets true, because tenant A does have one — just not the one on screen.

ownsRun at :18-20 does not have this shape. It uses whereKey($runId) and is row-keyed, so it answers the question a caller holding a record actually has.

The two name-keyed checks are the right question for a caller that holds only a name, which is why they read correctly in isolation. They are the wrong question for a caller that holds a record, and nothing in the signature says which caller is which. A surface that reaches for the obviously-named policy method gets an answer that looks like authorisation and is not.

Found while building module-ecommerce-reporting-filament, which works around it by comparing the record's own tenant_id in DefinitionResource and SubscriptionResource rather than calling the policy. RunResource::canView() calls ownsRun and is fine.

Suggested shape: keep the name-keyed checks for name-holding callers under names that say so, and add row-keyed ownsDefinitionRecord/ownsSubscriptionRecord taking the key — or take the key everywhere and let name-holding callers resolve first.