seaweedfs: no e2e case walks lowering volumeSizeLimitMB on a live instance #4302

Lowering master.volumeSizeLimitMB on a live instance, which the platform now leaves to the operator for every instance that predates the 400 default, takes every volume already at or above the new value out of the master's writable set, so each affected collection needs a successful grow before its next write lands. That transition is measured on a local rig and written up for operators in docs/operations/seaweedfs-lowering-the-volume-size-limit.md, but nothing in the suite walks it: every existing case installs at one limit and stays there, so a change that made the transition worse would pass.

There is a route that does not fight the platform's own reconcile, and it only became available once the limit was exposed on the app chart. The tenant module's HelmRelease takes its values from the cozystack-values Secret and carries no spec.values (packages/apps/tenant/templates/seaweedfs.yaml), so moving the value on an instance the module created races its parent. An instance created directly against the API has no such parent, and master.volumeSizeLimitMB now appears in the seaweedfs-rd openAPISchema, so a SeaweedFS resource can carry it. The chart pins fullnameOverride: seaweedfs, so that instance needs a namespace of its own rather than a second release beside the first.

The shape: install at 1000, write into one bucket until a volume sits between the two limits, patch the CR to 400, then assert that a write to that same bucket still lands. That last write is what the test is for, since the failure is a write that times out while the disk still reports free space.

It is not in #4251 because of cost: a second instance plus enough written bytes to put a volume in the band is not cheap in the e2e sandbox. The route was worked out in review, in this comment.

One open question for whoever builds it: suite order. bucket-1-capacity shares the tenant-root SeaweedFS instance with every suite that provisions a bucket there, and chainsaw gives no ordering guarantee between tests. Its margin on the shipped volume is about eight collections at 400 MB and three volumes per grow, against its own three, cozy-backups and the unnamed default collection, so whether it holds depends on how many collections the suites before it have left behind when it runs. Its comment names only the default collection as the unknown. In the PR's e2e run it ran last, after the backup suites, and passed. A second instance brings its own budget into the same question, so where both sit in discovery order is worth deciding rather than inheriting.