fix(io-metrics): drop the rustfs-common edge by injecting the S3 telemetry observer (#7795)

* fix(io-metrics): drop the rustfs-common edge by injecting the S3 telemetry observer

dc700d366 (#7775) made the io-metrics leaf crate depend on rustfs-common
to publish typed telemetry trace events from S3HttpRequestGuard, which
breaks the backlog#1834 leaf-crate rule (io-metrics may only depend on
rustfs-s3-ops).

S3HttpRequestGuard now takes an optional fn-pointer completion observer
(operation, latency, 2xx?) and knows nothing about the trace bus. The
server builds guards through rustfs::server::s3_http_request_guard, which
attaches the observer only while a telemetry subscriber exists and owns
the S3Operation -> TelemetryTraceOperation mapping.

* chore(guard): admit #7785 s3s ratchet growth (+1 file, +4 lines)

#7785 landed the gateway key inventory admin handler after the
baselines were verified, leaving check_s3s_footprint.sh red on main
and every branch cut from it (measured 210 files / 1592 lines vs
209/1588 baselines).

The handler follows the house admin convention whose Operation::call
signature is s3s-typed (S3Request/S3Result), so it cannot route
through a non-s3s seam until the s3gate admin migration replaces the
admin router (rustfs/backlog#1677 F1); no local refactor can shed the
file-level import. Record the measured growth with rationale:
files 209 -> 210, s3_error! lines 1588 -> 1592.

* fix

* fix: resolve clippy gate failures in connect and CLI surfaces

- Box the two large CommandResult performance variants and
  LicenseRenewalOutcome::Installed (clippy::large_enum_variant)
- Return RelayError instead of () from RelayTransport::deliver and the
  test destination (clippy::result_unit_err)
- Drop an unused mut on the protected relay file handle (unused_mut)
- Pass the digest by value to base64 encoding and drop a redundant
  result_json clone (clippy::needless_borrows_for_generic_args,
  clippy::redundant_clone)

* fix(connect): resolve the remaining site-replication clippy errors

- Group the endpoint credential triple into SiteReplicationCredentials
  so SiteReplicationEndpoint::new takes 6 arguments
  (clippy::too_many_arguments)
- Take the build-feature validator by &str (clippy::ptr_arg); the
  validator closure stays because &String needs the deref coercion

* style: apply rustfmt to the site-replication credential grouping

* fix(connect): keep the CPU profile fixture off the ecstore import scan

#7811 used "rustfs_ecstore::disk::read_object" as the raw-symbol fixture
of the profile redaction test, which the architecture guard counts as a
direct rustfs_ecstore reference outside the compatibility boundaries
(its scan deliberately includes inline test modules). The accumulator
treats symbols opaquely, so use the internal rustfs::storage:: path that
keeps the fixture realistic without matching the import scanner.

* fix

* fix

* fix

* fix

---------

Co-authored-by: Hauser <housemecn@gmail.com>

scripts/check_s3s_footprint.sh

@@ -61,8 +61,17 @@ cd "$(dirname "$0")/.."
 # 213 -> 212 on 2026-09-14: rustfs/backlog#1735 A4 moved rio's trailer
 # handle behind rustfs_rio::TrailerSource; the only adapter imports s3s through
 # the app storage_api shim, so crates/rio no longer references s3s.
-S3S_IMPORT_FILES_BASELINE=209
-S3_ERROR_LINES_BASELINE=1588
+# 209 -> 210 and 1588 -> 1592 on 2026-09-14: #7785 landed the gateway key
+# inventory admin handler (rustfs/src/admin/handlers/gateway_key_inventory.rs)
+# for the RUSTFS_S3_STACK switch after the baselines were verified, leaving
+# this guard red on main (measured 210/1592). The handler follows the house
+# admin convention whose Operation::call signature is s3s-typed
+# (S3Request/S3Result), so it cannot route through a non-s3s seam until the
+# s3gate admin migration replaces the admin router (rustfs/backlog#1677 F1);
+# no local refactor can shed the file-level import. Admit the measured
+# growth: +1 direct-s3s admin file, +4 s3_error! invocation lines.
+S3S_IMPORT_FILES_BASELINE=210
+S3_ERROR_LINES_BASELINE=1592
 # ecstore-scoped ratchet (rustfs/backlog#1842): the storage engine must not
 # know S3 wire/DTO types (ARCHITECTURE.md invariant 4). The S3-*consuming*
 # client was extracted to crates/s3-client, where s3s usage is legitimate;