cozystack-operator force-overwrites PackageSources it does not own #4001

What happens

installPlatformPackageSource in cmd/cozystack-operator/main.go applies every platform PackageSource with server-side apply and Force: true:

patchOptions := &client.PatchOptions{
    FieldManager: "cozystack-operator",
    Force:        func() *bool { b := true; return &b }(),
}

if err := k8sClient.Patch(ctx, ps, client.Apply, patchOptions); err != nil {
    return fmt.Errorf("failed to apply PackageSource %s: %w", packageSourceName, err)
}

There is no ownership check before the apply. If an object of that name already exists and belongs to somebody else, Force: true takes its fields over rather than reporting a conflict.

Why it matters

With the marketplace (#3940), a tapped repository materializes PackageSource objects under names it chooses for itself. A name that is free today can be shipped by the platform tomorrow.

When that happens, the platform upgrade silently overwrites the tap's object. No error, no Event, nothing the user can see — their application simply stops existing, and the cause is a platform upgrade that reported success.

The marketplace's own collision check cannot cover this, by construction: it runs at tap time, while the overwrite happens later, during an unrelated upgrade. It also holds under any naming policy, including one where no prefixes are reserved at all.

Expected behaviour

Break loudly instead of overwriting silently. A conflict on a PackageSource the operator does not own should fail the reconcile with a message naming the object and the conflicting owner, and leave the existing object untouched. An operator resolving it by hand is a much better outcome than a user discovering their data path was replaced.

Concretely: drop Force: true so server-side apply surfaces the field-ownership conflict, and let that error propagate. Optionally check ownership before applying so the message can be more specific than a raw SSA conflict.

Not in scope

The naming policy itself. Whether tapped repositories may use platform-shaped names is a separate decision; this issue holds either way, because the platform should never force-apply over an object it does not own.