Relax the Clone bound on watch channel construction

[tisonkun]

Motivation

watch::channel currently requires T: Clone, although constructing the channel and publishing values do not clone the payload. This prevents callers from using non-Clone state with the existing publication, replacement, and change-notification APIs.

Only the owning read methods, Receiver::get and Receiver::recv, need T: Clone. Their method-level bounds already express that requirement.

Proposed change

Relax the constructor from:

pub fn channel<T: Clone>(initial: T) -> (Sender<T>, Receiver<T>)

to:

pub fn channel<T>(initial: T) -> (Sender<T>, Receiver<T>)

Keep the existing T: Clone bounds and return types on Receiver::get and Receiver::recv. Construction, send, send_replace, subscription, handle cloning, has_changed, and changed should be usable with a non-Clone payload.

This is a compatible relaxation: existing callers retain the same types and behavior. It does not introduce borrowed reads or change the channel to store or return Arc<T>; callers can already select T = Arc<State> when they want shared owning snapshots.

Implementation and validation

• Update the constructor and document that only owning reads require Clone.
• Add focused coverage using a payload that does not implement Clone. Exercise publishing and observing a change, and verify that send_replace returns ownership of the previous value. Existing Watch integration tests provide the test style and cover existing Clone-based behavior.
• Use deterministic coordination for any pending-wait coverage, and run the applicable cargo x checks.
• Record the newly supported use with non-Clone values in the changelog.

The constructor is in asyncband/src/watch/mod.rs; the owning-read bounds are already localized on get and recv.

[tayfuryldz]

I'd like to take this. I’ll keep T: Clone only on the owning read methods (get/recv), relax the constructor, and add focused coverage with a non-Clone payload for publication/change observation plus send_replace ownership. I’ll also update the API docs/changelog and validate with the repository’s cargo x workflow before opening the PR.