Pin S3 and SMB connector peers

docs/CONNECTOR_BOUNDARY.md

@@ -19,6 +19,7 @@ normal product workflows and can share the same governance model:
 - Nextcloud through WebDAV
 - generic WebDAV
 - SMB through the optional `smb` extra
+- S3-compatible stores through the optional `s3` extra
 
 These providers are surfaced through connector descriptors at
 `GET /api/v1/files/connectors/providers`. Provider descriptors declare whether
@@ -60,11 +61,14 @@ Every provider must:
 - use a transport that pins every connection to a policy-validated DNS/IP answer
   and revalidates redirects; SDK transports without that guarantee fail closed
 
-Live SMB access is disabled in all modes until `smbprotocol` initial connections
-and DFS referral targets can be pinned and policy-validated. An explicit IP is
-not sufficient because the server may still issue a referral to another peer.
-Live S3 access is likewise disabled until `boto3`/botocore can be bound to the
-pinned transport, including SDK-managed redirects and endpoint discovery.
+SMB initial connections, reconnects, aliases, and DFS referral targets are
+created through a Files-owned pinned `smbprotocol` transport. S3 HTTP/HTTPS pools
+use the equivalent botocore adapter for every connection selected by retries,
+redirects, endpoint discovery, and virtual-host addressing. Both adapters apply
+the deployment-wide private-network policy at socket creation. S3 keeps the
+configured hostname for TLS SNI and certificate verification, but does not use
+outbound proxies or ambient AWS credential discovery. An incompatible optional
+SDK release fails closed before a usable session or client is returned.
 
 ## Non-Goals For Files