fix(sync): three ways a UserGroup sync loses a permission silently

[cplieger]

A sync that creates a resource and a UserGroup permission on that same resource creates the group, adds its users, reports success, and applies no permission. Hit this on a live deployment: a service user was denied Execute on an Action the TOML grants it, and a second run applied it. Tracing that turned up two more ways the same path loses a permission silently. Three commits, readable one by one; commit 3 is independent of the other two.

Commit 1: apply UserGroups after resources, not before

user_groups::run_updates ran in the apply block under // No deps, ahead of every resource phase, and user_groups::get_updates_for_execution ran in the pre-computation block. That is where expand_user_group_permissions resolves each permission target through Matcher against all_resources_cache(), keeping only the targets it can match. A target naming a resource the same sync is about to create expands to nothing and is dropped with no error. The apply block already documents that later phases may depend on earlier ones, and Procedure is last for that reason; a UserGroup permission names a resource, so UserGroups belong there too.

The phase moves after Procedure and recomputes its deltas there, since the pre-computation expanded against the pre-sync cache (resource::create refreshes it). The early computation is kept only to feed the existing no-changes exit, which is why the TOML is cloned. The recompute does not propagate its error: every resource phase has been applied by then, and a ? would add a mid-sync abort that skips deploy_from_cache and the last_sync_ts bookkeeping. It logs into the update instead, as run_updates already does.

Cost: one extra get_updates_for_execution per sync when include_user_groups is on (a find_collect over user_groups, one over users, one ListUserTargetPermissions per group). If you would rather avoid the second pass, the expansion could move inside run_updates; that is a larger change and I did not want to guess.

Interactions checked: with delete = true, delete_all_permissions_on_resource purges a removed resource's rows in the same phase, so the recompute reaches the same end state the old order did by granting then deleting. A failing resource phase still runs the UserGroup phase afterwards, as before. Wildcard targets now expand over resources created by the same sync and no longer emit doomed updates against ones it deleted.

Commit 2: report permission targets that match nothing

The remaining case is a target that is not resolvable at all (a typo, a renamed resource, a pattern matching nothing). It was dropped and the sync was green. The expansion now collects each target that expanded to nothing, and run_updates prints one WARN line per unique target into the UserGroups log, naming the group and the target. An empty target id is reported the same way. Reported rather than fatal, because a pattern that legitimately matches nothing right now is supported configuration and the sync cannot tell the two apart.

Details worth your attention:

• The reported list comes from the post-resource recompute, so a target naming a resource this sync just created is not reported. The pre-resource list only feeds the RunSync no-changes gate, so a sync whose only finding is a dropped target no longer exits "nothing to do" before the report is written. That run now proceeds through the apply block as a no-op and updates last_sync_ts / last_sync_hash; displayed sync state and the pending-updates alert derive from view-path data and are unaffected. This is the one behavior change beyond the log line.
• Execute-tab visibility comes from the view path, which discards this list, so a sync whose sole finding is a bad target does not grow an Execute button to surface it. Fixing that means an informational field on ResourceSyncInfo; say the word if you want it.
• System targets are excluded from the check; they are not name matched.
• get_updates_for_execution now returns a 4-tuple. A struct would read better (precedent in SyncDeltas); I kept the tuple to hold the diff to the bug.

Commit 3: stop the sync revoking System permissions it exported itself

convert_user_groups writes a group's System permissions into the file, expand_user_group_permissions drops every System target on the way back in, and to_remove sets every original permission missing from the incoming list to PermissionLevel::None. So syncing back a file Komodo itself exported revokes the group's System permissions, and the view shows a permission removal nobody asked for on every refresh. The fix is pass-through: a System target names no resource, so nothing needs expanding.

Severity: this restores round-trip fidelity, not access. get_user_permission_on_target returns None for System unconditionally, so the permission grants nothing today either way; what changes is that the sync stops deleting a row a user created and stops rendering an unsettleable diff. The symmetric alternative is to filter System out of convert_user_groups and make to_remove skip System; I picked pass-through because it is one branch and keeps export and import agreeing.

Verification

cargo check -p komodo_core and cargo check -p komodo_core --tests clean with no new warnings, cargo fmt --check clean. Reproduced the original failure and the fix against a live Core (a sync creating an Action plus a group granting Execute on it: permission missing before, applied after). No test added: bin/core has no test module and these paths need a database and the resource cache. WARN with Color::Red follows the precedent in sync/file.rs.