e2e: backup access preflight cleanup cannot delete its object and warns on every failure past PUT #4244

Describe the bug

The exit trap in hack/e2e-chainsaw/_lib/backup-access-preflight.sh is meant to delete the preflight object when the round trip failed after the upload landed. It cannot do that, for two reasons that sit on the same path.

The trap kills the port-forward first. mc rm then runs against https://127.0.0.1:${local_port}, which is the tunnel that was just torn down, so it gets a connection refusal. Kill and wait are lines 41-50, the delete is lines 51-55.

Separately, uploaded is set only after timeout 15 mc cp returns zero (lines 106-108). An upload that lands and then hits the 15 second wall leaves uploaded=false, so the trap does not even try. Fixing either one alone leaves cleanup still not working, which is why both are here rather than in two issues.

Environment

• Cozystack: main at 79602e9ca
• In-tree e2e lane

To Reproduce

Have the preflight fail anywhere after a successful PUT, for example by making the download fail. The object stays in the bucket and the warning below is printed.

Expected behaviour

The trap deletes the object it created, or explains why it could not in a way that names the cause.

Actual behaviour

The object stays under .cozystack-e2e-preflight/ in the bucket, and this is printed on every failure that got past PUT:

WARNING: could not remove failed S3 preflight object <bucket>/<object>

The warning is the part worth fixing first, ahead of the leak. It carries no signal, because it fires identically whether S3 is broken or the tunnel is simply gone, and it now lands directly beside the failure evidence that #4242 makes readable. A run that was made legible should not come with a misleading warning attached to it.

Additional context

The leak itself is small: these buckets go away with the tenant the suite deletes afterwards. The defect is real, the blast radius is not large, and I would rather say that than dress it up.

Checklist

• I have checked the documentation
• I have searched for similar issues
• I have included all required information
• I have provided clear steps to reproduce
• I have included relevant logs