Bug: `#[derive(Task)]` rejects `TaskState<T>` behind a type alias

[ZialeHub]

Description

The Task derive macro checks whether each field's type is TaskState by comparing the last path segment identifier to the string "TaskState". Type aliases that resolve to TaskState are rejected with a
compile_error! because their identifier is the alias name, not TaskState.

Affected file

• pulsync-derive/src/task.rs — line 117 (segment.ident != "TaskState" check)

Reproduction

  type Counter = TaskState<u32>;

  #[derive(Task, Salt)]  // compile_error!: "State fields must be TaskState<T>"
  struct MyTask {
      count: Counter,  // type alias — rejected
  }

Impact

Users cannot abstract over TaskState at the type level. Any type alias, even one pointing directly to TaskState, silently breaks the derive with a confusing error message.

Fix

Either:

1. Document clearly that type aliases are not supported (cheapest fix).
2. Accept any type at the field level and let the user's own type error surface naturally if it doesn't implement the required traits.
3. Support a #[task(state)] field attribute to explicitly opt fields into the TaskState wrapping instead of relying on type name inspection.