feat(seaweedfs): bump chart to 4.48 and backport Gateway API HTTPRoutes - #4879

[MAJOR] The 4.45->4.48 image bump silently revokes Object Lock operations from tenant COSI credentials on upgrade

Bumping appVersion here rolls every pod to chrislusf/seaweedfs:4.48, and 4.48 splits the single ACTION_WRITE/ACTION_READ check on the object-lock routes into dedicated per-operation actions that no cozystack BucketAccessClass grants. Verified against pinned upstream source:

• weed/s3api/s3api_server.go: at 4.45 PUT ?retention/?legal-hold/?object-lock used ACTION_WRITE (lines 853, 855, 948) and the GETs used ACTION_READ (860, 862, 947); at 4.48 each demands a dedicated action, ACTION_PUT_OBJECT_RETENTION (="PutObjectRetention"), ACTION_PUT_OBJECT_LEGAL_HOLD, ACTION_GET_OBJECT_RETENTION, ACTION_GET_OBJECT_LEGAL_HOLD, ACTION_GET_BUCKET_OBJECT_LOCK_CONFIG, ACTION_PUT_BUCKET_OBJECT_LOCK_CONFIG (lines 888, 890, 895, 897, 982, 983).
• weed/s3api/auth_credentials.go:1903 CanDo matches an action by exact string or <action>:<bucket>/wildcard. There is no mapping from Write to any of the new actions.
• weed/s3api/s3api_object_handlers_put.go:2138 checkObjectLockHeaderPermission is new at 4.48 (absent at 4.45) and gates a plain PutObject carrying x-amz-object-lock-* headers behind PutObjectRetention/PutObjectLegalHold (call sites 2218, 2223).
• The pinned COSI driver ghcr.io/seaweedfs/seaweedfs-cosi-driver:v0.3.1 (pkg/driver/provisioner.go:568-571) grants only ["Read","Write","List","Tagging"] for readwrite and ["Read","List"] for readonly, scoped <action>:<bucket> (line 290). v0.3.1 is the latest tag and no BucketAccessClass in the tree grants the dedicated actions.

The surface is on by default: the package overlay sets cosi.enabled: true (packages/system/seaweedfs/values.yaml:294) and patches/cosi-bucket-class-lock-readonly.patch ships a -lock BucketClass (objectLockEnabled: true, COMPLIANCE, 365d) plus readwrite/readonly BucketAccessClasses, none touched by this PR. Scenario: a tenant on a lock bucket today can run put-object-retention, put-object-legal-hold, get-object-retention, get-object-lock-configuration, or upload with --object-lock-mode. After the s3 pods roll to 4.48 every one of those returns 403, and no BucketAccessClass can hand back the grants. Plain PUT/GET and the server-side bucket-default retention still work, which is why this is MAJOR and not CRITICAL, but client-driven WORM management breaks for existing tenants across the upgrade and the change is nowhere recorded. Options: pin image.tag: "4.45" under the 4.48 chart, or carry a COSI-driver change that grants the six dedicated actions.

IvanHunters Confirmed against the 4.45 and 4.48 sources. I fixed it in #4893 instead of pinning the image, and this PR now sits on top of it. There the COSI driver grants the dedicated Object Lock actions to new credentials, and a hook in seaweedfs-system adds them to identities issued earlier. Checked on a real 4.48: a key with Read and Write on a lock bucket got AccessDenied on put-object-retention before the hook and worked after it.

[MINOR] Default S3 backendRef targets the TLS main port with no BackendTLSPolicy, so an enabled route does not work out of the box

In this package s3.port (8333) serves HTTPS (patches/s3-tls-main-port.patch; probes render scheme: HTTPS and the Ingress backend-protocol: "HTTPS"). A Gateway sends plaintext to a backendRef unless a BackendTLSPolicy exists, and the chart emits none while values.yaml does not mention it. An operator who flips s3.httpRoute.enabled: true with a parentRef gets an Accepted/ResolvedRefs route whose every request resets or 502s, while the Ingress path keeps working. You document the BackendTLSPolicy requirement in the patch header and the PR body (CodeRabbit raised the same point), but the shipped chart default is non-functional. Non-blocking: the knob is off by default and absent from the SeaweedFS ApplicationDefinition schema, so no tenant can turn it on through the dashboard today. Worth a one-line note in values.yaml next to the httpRoute block.

Added a note next to s3.httpRoute in values, through the patch. I did not render a BackendTLSPolicy from the chart: it needs a CA ConfigMap and a hostname that matches the s3 certificate, and the route is off and not in the app schema. The note covers only the standalone gateway without httpsPort. With httpsPort set, or in filer-embedded and all-in-one mode, that port is plaintext.

[MINOR] Comment (and the matching PR-body text) misdescribes the s3 backend/service naming

This says upstream resolves the s3 backend through componentName (<fullname>-s3) and that backend and service names coincide only while fullnameOverride equals the chart name, so each case overrides fullnameOverride to keep the divergence visible. The patched template does not behave that way: s3-httproute.yaml derives the backend as printf "%s-s3" (include "seaweedfs.name" .) and s3-service.yaml (via s3-service-name.patch) names the Service {{ template "seaweedfs.name" . }}-s3, so both use seaweedfs.name and coincide unconditionally. The fullnameOverride set here only changes the route's own metadata.name (componentName), which no assert compares against the backend, so there is no divergence to expose. Rendered: backend seaweedfs-s3 equals service seaweedfs-s3 with default values, with fullnameOverride=seaweedfs-system, and both become foo-s3 under nameOverride=foo. The routing is correct, only the explanation is wrong.

Rewrote the comment and the PR body. Both names come from seaweedfs.name. fullnameOverride is set so that upstream's componentName form renders a different name and fails the test.

[NIT] No case pins the two default-rule branches the values comment promises

values.yaml says a rule without backendRefs routes to the service and an empty rules list routes all traffic there. Both branches live in range .Values.X.httpRoute.rules | default (list dict) and {{- with .backendRefs }} ... {{- else }}, and no test sets rules: [{matches: ...}] or rules: [{backendRefs: []}]. They render correctly today, but the suite would not catch a regression in the fallback.

Added both: a rule with matches and no backendRefs, and an empty rules list.