feat: add blob bucket backend [7/n]

[sadhansood]

Description

This adds an explicit blob bucket store path to walrus-sdk behind the internal store backend seam.

The owned blob APIs stay unchanged. Instead, this PR adds a separate bucket backend and a new explicit SDK API for storing blobs into an existing bucket. The bucket path:

• ensures the backing storage pool is active
• extends the pool lifetime if needed
• increases pool capacity if needed
• registers pooled blobs in the bucket
• uploads blob data and collects certificates
• certifies the pooled blobs on Sui

To support that cleanly, the internal store lifecycle now allows a backend-specific final result type, and the bucket flow gets its own BlobBucketStoreResult plus bucket-specific post-registration states.

This PR also exposes a public blob_bucket_storage_pool_status helper from walrus-sui so the SDK can size and extend buckets without reaching into private read-client internals.

One intentional constraint in this PR: the bucket store path does not automatically retry the full operation across epoch changes. Pooled blob registration is not idempotent, so a full retry after partial success could create duplicate pooled blobs in the bucket.

Test plan

• rustup run 1.86 cargo fmt -- --config group_imports=StdExternalCrate,imports_granularity=Crate,imports_layout=HorizontalVertical
• cargo clippy --workspace --all-features --tests --no-deps -- -D warnings
• cargo check -p walrus-sdk
• cargo check -p walrus-e2e-tests --tests

I also added a new ignored e2e bucket test in crates/walrus-e2e-tests/tests/test_client.rs

---

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that
a user might notice and any actions they must take to implement updates. (Add release notes after the colon for each item)

• Storage node:
• Aggregator:
• Publisher:
• CLI: