Deleting a container that still exists in the DB, but not in youki, fails

The deletion fails and the container stays in the database.

Example:

$ feos-cli container list
CONTAINER_ID                           STATE           IMAGE_REF
-------------------------------------- --------------- ----------------------------------------
b98b86c4-9e23-43a8-add8-8de8157b1310   Stopped         <image-ref>

$ feos-cli container delete b98b86c4-9e23-43a8-add8-8de8157b1310
Requesting to delete container: b98b86c4-9e23-43a8-add8-8de8157b1310...
Error: status: Internal, message: "Runtime adapter error: Task service communication failed: status: NotFound, message: \"b98b86c4-9e23-43a8-add8-8de8157b1310\", details: [], metadata: MetadataMap { headers: {\"content-type\": \"application/grpc\", \"date\": \"Tue, 30 Dec 2025 13:56:52 GMT\"} }", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc", "date": "Tue, 30 Dec 2025 13:56:52 GMT"} }

$ feos-cli container list
CONTAINER_ID                           STATE           IMAGE_REF
-------------------------------------- --------------- ----------------------------------------
b98b86c4-9e23-43a8-add8-8de8157b1310   Stopped         <image-ref>

Desired Behavior

Whatever the reason why the container does not exist in youki anymore, the delete command should still delete the container from the database to clean up the state. The result can contain a warning that the underlying container did not exist anymore. It might still return a NotFound error.

Start at the Rust implementation of the container delete command and trace how the runtime adapter handles a NotFound response from youki. Verify the database cleanup path and how warnings or errors are returned. Done means deleting a database record succeeds when the underlying container is already absent, with the documented error or warning behavior covered by a test.