fix(bucket): propagate bucket deletion to peer metadata caches (backlog#646) (#4326)

The peer `DeleteBucketMetadata` RPC handler was a stub that returned
success without doing anything, and the delete-bucket flow never sent
the notification in the first place. As a result, after a bucket was
deleted other nodes kept serving its stale cached metadata.

Wire the whole path end to end:
- ecstore: add an in-memory `remove_bucket_metadata` (free fn) and
  `BucketMetadataSys::remove`, the counterpart to `set_bucket_metadata`,
  and export it through the `api::bucket::metadata_sys` facade.
- node_service: `handle_delete_bucket_metadata` now validates the bucket
  name and actually drops the cached metadata for it.
- bucket_usecase: after a successful delete_bucket, notify peers via
  `notification_sys.delete_bucket_metadata` in the background, symmetric
  to the existing `notify_bucket_metadata_reload` path.

Also update the delete-bucket-metadata unit test to assert the
empty-bucket rejection instead of the old always-success stub, and drop
an unused `tracing::debug` test import left over from #4322.

Verified: cargo fmt; cargo check -p rustfs-ecstore; cargo test -p rustfs
--lib --features rio-v2 test_delete_bucket_metadata_empty_bucket; arch
guardrail scripts pass.

crates/ecstore/src/api/mod.rs

@@ -99,7 +99,7 @@ pub mod bucket {
             get_lifecycle_config, get_logging_config, get_notification_config, get_object_lock_config,
             get_public_access_block_config, get_quota_config, get_replication_config, get_request_payment_config, get_sse_config,
             get_tagging_config, get_versioning_config, get_website_config, init_bucket_metadata_sys, list_bucket_targets,
-            set_bucket_metadata, update,
+            remove_bucket_metadata, set_bucket_metadata, update,
         };
     }