Delete intents should treat backend 'path not found in tree' as idempotent success

[steiler]

Summary

When deleting config intents, backend errors like path not found in tree are currently treated as hard failures, but this case is effectively idempotent delete (path already absent).

Observed behavior

In SROS delete scenarios, config-server marks the config as failed/unrecoverable after receiving backend message similar to:

• reached ... but child ... does not exist
• path not found in tree

This prevents expected cleanup flow and causes follow-on test failures.

Expected behavior

For delete intents, path not found should be treated as successful no-op/idempotent delete, not unrecoverable config failure.

Suspected area

pkg/sdc/target/manager/transactor.go

• handleTransactionErrors
• delete-intent branch handling (deletedConfigsToTransact)

Impact

• false negative failures during delete
• cleanup/orphan-policy behavior becomes inconsistent
• subsequent suites inherit broken state

Repro context

Integration run testrun01 includes failures such as:

• Delete And Verify intent4
• Delete ConfigSet with orphan policy keeps device config on all targets - intent1

Request

Please classify backend path not found delete errors as idempotent success (or explicitly ignorable) in delete error handling paths.