[Bug] Shared-resource conflict message carries an empty function name and a stray cue/format error

Is there an existing issue for this?

Searched the open issues, nothing matching.

Affected area

Workflow / WorkflowStepDefinition

KubeVela version

Controller v1.10.0, built from master at e6bbce3fc.

Kubernetes version and distribution

v1.31.5+k3s1, k3d

Describe the bug

When two Applications claim the same object, the shared-resource conflict is detected correctly and the second Application's workflow step fails, which is the right outcome. The message the user reads carries two pieces of noise around the useful part:

function call error for : Dispatch: pre-dispatch dryrun failed: Found 1 errors.
[(cannot apply ApplyOption: existing object ConfigMap default/contested-cm is
managed by other application default/owner-a)]
(value: cue/format: unsupported node type <nil>)

The part in the middle is exactly what an operator needs. Around it:

1. function call error for : Dispatch: has an empty name before the colon, so the sentence reads as though a field is missing.
2. (value: cue/format: unsupported node type <nil>) is a formatting failure leaking into a user-facing message. It suggests something went wrong with the error rendering, which sends people looking for a CUE problem in their own Application that is not there.

This is cosmetic, not functional. The conflict is caught, nothing is overwritten, and the Application correctly stays out of running. Filing it because shared-resource conflicts are a normal thing to hit and this is the message people will be reading when they do.

To reproduce

Apply two Applications that each declare the same ConfigMap. No traits, policies, or addons involved.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata: {name: owner-a, namespace: default}
spec:
  components:
    - name: shared-cm
      type: k8s-objects
      properties:
        objects:
          - apiVersion: v1
            kind: ConfigMap
            metadata: {name: contested-cm, namespace: default}
            data: {owner: "owner-a"}

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata: {name: owner-b, namespace: default}
spec:
  components:
    - name: shared-cm
      type: k8s-objects
      properties:
        objects:
          - apiVersion: v1
            kind: ConfigMap
            metadata: {name: contested-cm, namespace: default}
            data: {owner: "owner-b"}

$ kubectl apply -f owner-a.yaml -f owner-b.yaml
$ kubectl -n default get app owner-a owner-b
NAME      COMPONENT   TYPE          PHASE             HEALTHY
owner-a   shared-cm   k8s-objects   running           true
owner-b   shared-cm   k8s-objects   runningWorkflow

$ kubectl -n default get app owner-b \
    -o jsonpath='{range .status.workflow.steps[*]}{.name}: {.message}{"\n"}{end}'
shared-cm: function call error for : Dispatch: pre-dispatch dryrun failed: Found 1 errors. [(cannot apply ApplyOption: existing object ConfigMap default/contested-cm is managed by other application default/owner-a)] (value: cue/format: unsupported node type <nil>)

Expected behavior

Something closer to:

shared-cm: pre-dispatch dryrun failed: existing object ConfigMap default/contested-cm is managed by other application default/owner-a

Specifically, the empty name in function call error for : should either be filled in or the prefix dropped, and the trailing cue/format failure should not be appended to a message whose cause has nothing to do with CUE formatting.

Screenshots or logs

Covered above.

Additional context

Reproduced with PreDispatchDryRun enabled, which is the chart default. The same wrapping appears for any object-level conflict, not just ConfigMaps.

Suggested labels for triage: type/bug, area/controller, good first issue, effort/small.