[Bug] resourceKeeper.Delete ignores shared-resource, garbage-collect propagation, and orphan-finalizer protections

Is there an existing issue for this?

• I have searched the existing issues

Affected area

Application controller

KubeVela version

main @ 6ac1ea70d (post v1.11.0)

Kubernetes version and distribution

Not version-specific — reproduced against a fake client in a unit test, no live cluster needed.

Describe the bug

resourceKeeper.delete() (pkg/resourcekeeper/delete.go) calls h.Client.Delete() unconditionally. The sibling garbage-collection path, DeleteManagedResourceInApplication in pkg/resourcekeeper/gc.go, checks three things before actually deleting a resource:

1. Whether the resource is still shared with another Application (oam.dev/shared-by annotation) — if so, it unshares (removes this app as a sharer) instead of deleting.
2. The garbage-collect policy's per-rule propagation setting (GarbageCollectPolicySpec.FindDeleteOption) — an orphan rule releases the resource (strips app-ownership labels, Update instead of Delete) instead of deleting it.
3. The Application's orphan-resource finalizer (app.oam.dev/orphan-resource) — same release behavior.

resourceKeeper.delete() checks none of these. It's reachable from any custom WorkflowStepDefinition that calls the documented vela/kube CUE action kube.#Delete without a filter (see packages/kube in the kubevela/workflow module) — so a workflow step in one Application can silently delete a resource another Application still depends on via a shared-resource policy, or delete a resource the user explicitly asked KubeVela to orphan.

To reproduce

1. Two Applications share a resource via the shared-resource policy (oam.dev/shared-by annotation lists both).
2. One Application's workflow calls kube.#Delete on that resource (or the resource is otherwise deleted via resourceKeeper.Delete).
3. The resource is deleted outright — the other Application silently loses it, instead of just having its own app removed as a sharer.

Same outcome for a resource covered by a propagation: orphan garbage-collect policy rule, or an Application carrying the app.oam.dev/orphan-resource finalizer.

Expected behavior

resourceKeeper.delete() should apply the same three checks DeleteManagedResourceInApplication already applies during GC, so explicit deletion respects the same protections automatic garbage-collection does.

Screenshots or logs

No response

Additional context

git log -S on both the GC-policy propagation check (gc.go, PR #6059, June 2023) and the shared-resource check (gc.go, PR #5330, January 2023) shows both landed well after pkg/resourcekeeper/delete.go was last substantively touched (August 2022) — this reads as "feature added to the GC path, sibling explicit-delete path never updated" rather than a deliberate design choice.