SubscribeToReport upserts on (tenant, name) alone, so one subscriber's subscription can be reassigned to another person

Found while building module-ecommerce-reporting-api.

Actions\SubscribeToReport upserts on (tenant_id, name):

return ReportSubscription::query()->updateOrCreate(
    ["tenant_id" => $tenantId, "name" => $name],
    ["subject_ref" => $subjectRef, "destination_ref" => $destinationRef, ...],
);

subject_ref and destination_ref are in the update half, so a second call naming the same
subscription name with a different subject silently rewrites whose subscription it is and where it is
delivered. There is no error and nothing in the delivery history records that the owner changed —
the next attempt simply goes somewhere else.

The unique key is (tenant_id, name), so this is the index working as designed; the question is
whether the action should treat a name already held by a different subject as a collision rather than
as an amendment.

The API package refuses it before calling the action, using the two policy methods that already
exist:

if (CustodyPolicy::ownsSubscription($tenantId, $name)
    && ! CustodyPolicy::subjectMayRead($tenantId, $name, $subjectRef)) {
    // 409
}

That closes it for one caller. A second caller of SubscribeToReport — the Filament surface, a
console command, a host job — would have to repeat the check, which is the call-site convention the
module deliberately avoids everywhere else. The guard belongs in the action.

Start with the Actions\SubscribeToReport action and inspect the existing CustodyPolicy::ownsSubscription and subjectMayRead methods, along with the API package's collision check. Ensure a subscription owned by a different subject is rejected before updateOrCreate can rewrite it, while valid same-subject calls continue to work; verify the behavior through the relevant action tests or caller checks.