fix(sync): do not blank a ResourceTarget id when the lookup misses

[cplieger]

Managed-mode writeback can emit TOML that Komodo itself cannot parse, which leaves the sync permanently broken until someone edits the file by hand. Hit this on a live deployment; the deploy pipeline stopped until I removed the offending line manually.

What happens

A Commit Sync wrote this into my resources.toml:

[[alerter]]
name = "Discord-stack-state"
[alerter.config]
alert_types = ["StackStateChange"]
resources = [{ type = "Stack" }]

Every read of the file after that failed:

ERROR: failed to read resources from ".../resources.toml"
  1: failed to parse resource file contents
  2: TOML parse error at line 1548, column 14
     resources = [{ type = "Stack" }]
                  ^^^^^^^^^^^^^^^^^^
     missing field `id`

Why

Three existing behaviours compose into an unparseable file:

1. replace_resource_target_ids! rewrote each id to the resource name with .map(|r| r.name.clone()).unwrap_or_default(), so a missed lookup yields an empty String.
2. ResourceTarget is adjacently tagged, #[serde(tag = "type", content = "id")] (client/core/rs/src/entities/mod.rs), so id is required to deserialize.
3. TOML_PRETTY_OPTIONS sets skip_empty_string: true (bin/core/src/sync/toml.rs), so the now-empty id is omitted from the emitted table.

Result: { type = "Stack" }, valid TOML syntax but not a valid ResourceTarget.

In my case the lookup missed because the file supplied the target by name, which is how every other synced reference is written, while the cache is keyed by id. Whether names should be accepted there is a separate design question and this PR does not touch it. This change only stops a miss from corrupting the file.

The change

Leave the id untouched when the lookup misses. The only behavioural difference is what happens on a miss, and the previous outcome on a miss was a file that cannot be read back.

Possibly the same class elsewhere

DeploymentImage::Build is also adjacently tagged and its build_id is blanked the same way in ReplaceIds for Deployment, so it looks reachable in principle. I have not reproduced that one and did not want to widen an urgent fix on an untested hypothesis, so I have left it alone. Happy to extend the PR if you would like it covered.

The plain String config fields nearby (server_id, swarm_id, linked_repo, builder_id) are unaffected, since an empty string there is still parseable.

Verification

cargo check -p komodo_core clean with no new warnings, cargo fmt leaves the change untouched. I have not added a test: bin/core has no test module today (one #[cfg(test)] in the whole repo, in lib/command) and the macro reads the global all_resources_cache(), so a unit test would need new scaffolding. Glad to add one if you point me at the shape you would want.