bundle plan fabricates recreate on shared UC schemas/volumes for second developer under mode: development (direct engine, 1.4.0–1.8.0)

[carlosalzate74]

Describe the issue

On CLI 1.8.0 with engine: direct, bundle plan reports recreate on canonical UC schemas/volumes when a second developer's profile evaluates a shared mode: development target — even though no config assigns a per-user value to those resources. Only the sibling pipeline resource's schema: field carries a per-developer override; the schema/volume resource itself declares a static name. Confirmed via full-repo search: no resources.schemas..name or resources.volumes..name override exists anywhere.

The first developer's plan (same repo, same CLI version) correctly shows skip for these same resources. Since both developers are bound to the identical canonical resource (bind returns "Resource already managed" when the second developer attempts it), an accidental deploy under this plan would recreate a live, shared, data-holding schema — not an isolated per-developer object.

Configuration

targets:
dev:
mode: development
resources:
pipelines:
pl_highnote_ingest:
schema: dev_${workspace.current_user.short_name}
configuration:
target_schema: dev_${workspace.current_user.short_name}

Schema resource itself: resources.schemas.bronze_highnote.name: highnote (static, no override).

Steps to reproduce the behavior

1. Dev A deploys canonical schemas via SP profile to dev-shared, binds them to their personal dev target.
2. Dev B (same repo/config, different profile) attempts the same bind — CLI confirms "Resource already managed" (same resource).
3. Dev B runs bundle plan --target dev --profile B.
4. Plan shows recreate on the schema, with new_state.name set to Dev B's personal-target string — a value never assigned to that resource in config.

Expected Behavior

skip for unchanged canonical schema/volume resources, regardless of which developer's profile evaluates the plan — matching Dev A's own (correct) plan output for the same resource.

Actual Behavior

recreate, with a fabricated new_state.name sourced from the pipeline's per-user override, not the schema resource's own config.

OS and CLI version

1.8.0, engine: direct, Windows

Is this a regression?

Same behavior present on 1.4.0 for Dev B — not introduced by the 1.8.0 upgrade. Dev A's plan on 1.8.0 is correct, so this is profile/state-specific, not purely version-specific.

Debug Logs

bundle plan --target dev --profile B --log-level=debug

debug_log.txt