fix(controller): bound every reconcile so one stuck call cannot wedge a controller

[duckhawk]

What the run showed

On the e2e run for #37 the controller went silent mid-suite:

17:48:21  [Reconcile] start for ObjectStore "system"     ← last line in the log
   …                                                       nothing, for 33 minutes
17:51:53  (the Full ObjectStore is created)               ← never reconciled at all
18:21:55  the Full spec gives up after 30 minutes

Requeues are queue-internal and cannot be dropped, so the worker was inside a call that never returned. With MaxConcurrentReconciles: 1 that is the entire controller — system, e2e-osc-light and the brand-new e2e-osc-full all queued behind it — and all eight full / full-highredundancy specs failed for want of a cluster nobody was building. (The other controllers had nothing to do in that window, which is why the log is completely quiet rather than partially.)

Nothing in the module noticed: a wedged worker emits no error, no event, no log.

Fix

A reconcile context carries no deadline of its own, and these reconcilers talk to backends over HTTP, exec into data-plane pods and wait on the API server. Every Reconcile now runs under a deadline — RECONCILE_TIMEOUT_SECONDS, default 300s — so a call that stops answering ends as an error naming the object and is retried, instead of taking the controller out of service indefinitely.

Honest limits

This does not say which call hung; that evidence was not in the logs, and I am not going to guess at a culprit. What it does is make the next occurrence self-reporting: the deadline turns silence into a logged failure against a named object, and the requeue keeps the rest of the module moving.

The e2e diagnostics also print the leader lease now (holder + renew age). When a controller goes quiet, that is what separates "the leader is stuck" from "leadership moved to another pod" — the log alone cannot tell them apart, and this run cost a full diagnosis cycle to that ambiguity.

Stacked

Branched on #37 (which is branched on #36), so a single e2e run exercises the SeaweedFS IAM guard, the Heavy teardown and this bound together. Merge order: #36 → #37 → this.

Also in this commit

Two things the same diagnosis pulled in:

• reconcileDelete returns only an error. Bounding the reconciles made the linter's point visible: the delete paths of the ObjectStore, Bucket and BucketAccess reconcilers always returned an empty ctrl.Result, so the value carried no information. The caller supplies the empty Result now. BucketClaim keeps its Result — its delete path really does requeue while a BucketAccess still references the claim.
• The e2e diagnostics dump every store and bucket, not just the shared ones. When a profile spec's own store failed, the dump was silent about it: a Full store stuck below Ready printed the healthy system store's conditions and nothing about the object that actually failed, so its BackendReady message — the one sentence that says why — was never in the log. Both kinds are cluster-scoped and few, so all of them are listed with phase, conditions, reasons and messages. This is what finally surfaced the SeaweedFS diagnosis in fix(seaweedfs): manage S3 IAM as per-identity files over the filer gRPC API #36.