[BUG]: Resource visibility semantics inconsistent between register_gateway() and _update_or_create_resources()

[crivetimihai]

Bug Report

Description

Resource visibility handling is inconsistent between initial gateway registration and subsequent gateway updates:

• register_gateway() (line ~956) preserves upstream resource-specific visibility:

  r_visibility = getattr(r, "visibility", None) or visibility

  This allows an upstream resource to specify its own visibility, falling back to the gateway's visibility.

• _update_or_create_resources() (line ~4228) always forces gateway.visibility:

  existing_resource.visibility = gateway.visibility

  This overwrites any resource-specific visibility on every gateway refresh.

Impact

If a resource was initially registered with a resource-specific visibility override, that override is silently lost on the first gateway refresh/update that succeeds. The resource's visibility is normalized back to the gateway's visibility.

Expected Behavior

Either:

1. Both paths should consistently respect resource-specific visibility, OR
2. Both paths should consistently use gateway visibility (and register_gateway should not have the override logic)

The current inconsistency means behavior changes depending on whether a gateway is being registered for the first time vs being refreshed.

Discovered During

Review of PR #3476

[crivetimihai]

Closing — verified fixed on current main. Both register_gateway() and _update_or_create_resources() now handle visibility consistently.

[crivetimihai]

Live verification update: All resources on the running instance are public visibility — cannot verify the fix for team-scoped visibility inheritance during gateway updates. Code analysis shows consistent handling, but no live proof. Leaving open.