test(s3): conform new test names to TestSSE*Integration so CI runs them

The two tests added in the previous commits had names that did NOT match
the patterns the test/s3/sse Makefile and .github/workflows/s3-sse-tests.yml
use to discover SSE integration tests:

  - test/s3/sse/Makefile `test` target:           TestSSE.*Integration
  - test/s3/sse/Makefile `test-multipart`:        TestSSEMultipartUploadIntegration
  - .github/workflows/s3-sse-tests.yml:           ...|.*Multipart.*Integration|.*RangeRequestsServerBehavior

Result: SSE-KMS coverage I added to TestSSERangeReadCoverageMatrix and
the Docker-Registry-shape multipart regression in
TestSSES3MultipartManyChunks_DockerRegistryShape were silently invisible
to CI even though the underlying test setup (start-seaweedfs-ci using
s3-config-template.json with the embedded `local` KMS provider) already
has SSE-KMS configured.

Renames:

  TestSSERangeReadCoverageMatrix              -> TestSSERangeReadIntegration
  TestSSES3MultipartManyChunks_...            -> TestSSEMultipartManyChunksIntegration

Both names now match `TestSSE.*Integration` (Makefile `test` target) and
TestSSEMultipartManyChunksIntegration additionally matches
`.*Multipart.*Integration` (CI's comprehensive subset). No behavior
change; only the function names move.

Verified locally against `weed mini` with s3-config-template.json:
TestSSERangeReadIntegration runs 96 leaf subtests across 4 SSE modes
(none, SSE-C, SSE-KMS, SSE-S3) x 3 size classes x 7-9 range patterns,
all passing, 0 skipped. The probe-and-skip in the SSE-KMS arm now only
fires for ad-hoc local setups that don't load any KMS provider; the
project's standard test setup loads the local provider, so CI has full
SSE-KMS range coverage.

test/s3/sse/s3_sse_integration_test.go

@@ -970,18 +970,18 @@ func uploadAndVerifyMultipartSSEObject(t *testing.T, ctx context.Context, client
 	}
 }
 
-// TestSSES3MultipartManyChunks_DockerRegistryShape pins the end-to-end fix for
-// issue #8908. A Docker Registry blob upload typically produces a multipart
-// upload with many small parts (5MB each) that totals 100MB+. After the
-// per-chunk metadata fix in #9211 and the completion backfill in #9224, the
-// remaining failure mode reported in #8908 was that GET would return truncated
-// bytes — Docker registry then computed a SHA over the truncated bytes and
-// reported "Digest did not match." The root cause was that
-// buildMultipartSSES3Reader (and its SSE-KMS / SSE-C peers) opened a
-// volume-server HTTP connection for EVERY chunk upfront, then walked them with
-// io.MultiReader; later chunks' connections sat idle while earlier chunks were
-// being consumed and could be closed by the volume server's keep-alive logic
-// under load, producing unexpected EOFs at the S3 client.
+// TestSSEMultipartManyChunksIntegration pins the end-to-end fix for issue
+// #8908. A Docker Registry blob upload typically produces a multipart upload
+// with many small parts (5MB each) that totals 100MB+. After the per-chunk
+// metadata fix in #9211 and the completion backfill in #9224, the remaining
+// failure mode reported in #8908 was that GET would return truncated bytes —
+// Docker registry then computed a SHA over the truncated bytes and reported
+// "Digest did not match." The root cause was that buildMultipartSSES3Reader
+// (and its SSE-KMS / SSE-C peers) opened a volume-server HTTP connection for
+// EVERY chunk upfront, then walked them with io.MultiReader; later chunks'
+// connections sat idle while earlier chunks were being consumed and could be
+// closed by the volume server's keep-alive logic under load, producing
+// unexpected EOFs at the S3 client.
 //
 // This test mirrors that shape: 25 parts of 5MB each (125MB total, 25
 // internal chunks since each part is below the 8MB internal chunk size) with
@@ -990,7 +990,12 @@ func uploadAndVerifyMultipartSSEObject(t *testing.T, ctx context.Context, client
 // one volume-server HTTP connection open at a time, which both eliminates the
 // idle-connection failure mode and makes resource usage proportional to one
 // chunk regardless of object size.
-func TestSSES3MultipartManyChunks_DockerRegistryShape(t *testing.T) {
+//
+// The function name ends in "Integration" so it is matched by the existing
+// `.*Multipart.*Integration` pattern in .github/workflows/s3-sse-tests.yml
+// (and the `TestSSE.*Integration` pattern in test/s3/sse/Makefile's `test`
+// target), so this regression coverage is run automatically in CI.
+func TestSSEMultipartManyChunksIntegration(t *testing.T) {
 	ctx := context.Background()
 	client, err := createS3Client(ctx, defaultConfig)
 	require.NoError(t, err, "Failed to create S3 client")

test/s3/sse/s3_sse_range_coverage_test.go

@@ -24,7 +24,7 @@ import (
 // and the read path has to stitch keystreams across chunks correctly.
 const internalChunkSize = 8 * 1024 * 1024
 
-// TestSSERangeReadCoverageMatrix is the canonical end-to-end coverage matrix
+// TestSSERangeReadIntegration is the canonical end-to-end coverage matrix
 // for HTTP range GETs across SSE modes, object size classes, and range
 // patterns. It supplements the per-SSE-mode TestSSExxxRangeRequests tests
 // (which are scoped to small single-chunk objects, ≤1MB) by also exercising
@@ -34,11 +34,17 @@ const internalChunkSize = 8 * 1024 * 1024
 // pinning range correctness here protects against any future regression in
 // per-chunk IV / PartOffset plumbing for partial reads.
 //
-// For SSE-KMS, the test probes once with a 1-byte SSE-KMS PUT and skips the
-// SSE-KMS subtests with a clear message if the local server has no KMS
-// provider configured (the default `weed mini` setup does not include one;
-// the Makefile's `test-with-kms` target does).
-func TestSSERangeReadCoverageMatrix(t *testing.T) {
+// The function name ends in "Integration" so it is matched by the existing
+// `TestSSE.*Integration` pattern that the test/s3/sse Makefile and the
+// .github/workflows/s3-sse-tests.yml CI flow use to discover SSE integration
+// tests; both flows already start the server using s3-config-template.json,
+// which configures the embedded `local` KMS provider with on-demand DEK
+// creation, so the sse_kms subtests run end-to-end in CI.
+//
+// For ad-hoc local runs against a server without any KMS provider, the test
+// probes once with a 1-byte SSE-KMS PUT and t.Skip's the sse_kms subtree
+// with a clear message rather than producing a 5xx-storm in the logs.
+func TestSSERangeReadIntegration(t *testing.T) {
 	ctx := context.Background()
 	client, err := createS3Client(ctx, defaultConfig)
 	require.NoError(t, err, "create S3 client")