GMS: recompute browsePathsV2 default when a container aspect lands

Follow-up to a review comment on #19547 (fix(ingest/dbt): resolve real container path for target-platform siblings).

Background

DefaultAspectsUtil.generateDefaultAspectsIfMissing fills in a missing browsePathsV2 aspect once, at entity creation, via:

buildDefaultBrowsePathV2(opContext, urn, false, entityService)  // false = useContainerPaths

useContainerPaths=false means the default always falls back to BrowsePathV2Utils.getDefaultDatasetPathEntries, which splits the raw dataset name on the platform's delimiter into plain-text folders, rather than trying BrowsePathV2Utils.getContainerPathEntries/aggregateParentContainers (the container-URN-based walk GMS already has, and the only production caller of useContainerPaths=true is the one-off BackfillBrowsePathsV2Step upgrade job).

Because this only runs once, at creation, an entity that gets a container aspect later (e.g. a stub/sibling entity created before the owning connector ingests it) never gets its browsePathsV2 recomputed. Client-side workarounds (see #19547) have to walk the container chain themselves and patch browsePathsV2 to compensate, which costs per-entity graph round trips that a server-side fix wouldn't need at all.

Proposal

When a container aspect is written for an entity whose current browsePathsV2 is still the plain-name/no-container default (i.e. it was never overwritten by an authoritative container-aware writer), recompute browsePathsV2 server-side using the existing aggregateParentContainers/getContainerPathEntries walk, the same one BackfillBrowsePathsV2Step already uses with useContainerPaths=true.

This would let entities self-correct as soon as their owning connector ingests them, without every client needing to reimplement the container walk to detect and patch the same condition.

Related

• #19547 - client-side (dbt) workaround for the specific case of target-platform sibling entities