refactor(replication): route app storage through ecstore (#4251)

docs/architecture/ecstore-module-split-plan.md

@@ -137,8 +137,8 @@ Current coupling:
 - admin replication extension target filtering and resync request construction
   stay behind the admin storage boundary instead of exposing replication work
   DTO construction to handlers;
-- scanner, admin, and storage-owner replication status/DTO consumers import
-  those contracts through the ECStore replication facade;
+- scanner, admin, storage-owner, and app storage replication status/DTO/helper
+  consumers import those contracts through the ECStore replication facade;
 - app object and multipart writes call object-replication boundary helpers
   instead of constructing replication work DTOs or choosing object replication
   operation types at the use-case layer;
@@ -187,10 +187,11 @@ Required contracts before crate movement:
   `crates/replication/src/storage_api.rs` inside `rustfs-replication`.
 - `EcstoreReplicationBoundaryImports`: ECStore-side imports from
   `rustfs-replication` are concentrated in replication `*_boundary.rs` modules.
-- `RuntimeReplicationFacadeConsumers`: scanner, admin, and storage-owner
-  replication status/DTO consumers import through `rustfs-ecstore`, while app
-  storage keeps direct object/delete helper calls inside its storage API
-  boundary.
+- `RuntimeReplicationFacadeConsumers`: scanner, admin, storage-owner, and app
+  storage replication status/DTO/helper consumers import through
+  `rustfs-ecstore`; runtime code under `rustfs/src` does not import
+  `rustfs-replication` directly, and the RustFS runtime/scanner crates do not
+  depend on it.
 - `StorageApiReplicationContracts`: storage-api delete DTO replication
   state/status helpers are concentrated in `crates/storage-api/src/replication.rs`
   until the underlying wire contracts can move without a