Fix async_tree double unpin

[lrubasze]

Fixes #3286

Problem

• light-base panics in parachain sync: panicked at runtime_service.rs:493:34: called Result::unwrap() on an Err value: ().
• Cause: sync_service/paraheads.rs unpins a relay block twice — once when its parahead fetch finishes, once when it's pruned.
• The prune path only re-unpins if the block's pruned_blocks async-op data is_none(). But AsyncTree::try_advance_output mapped a pruned Finished { reported: false } block to None instead of
  Some(user_data) (the old "TAsync thrown away silently / TODO" corner case).
• So a relay block whose parahead finished but was never reported before being pruned hits both unpin paths → double-unpin → Err(()) → panic.

Fix

• try_advance_output now returns Some(user_data) for any Finished pruned block, regardless of reported.
• The prune path then correctly sees "already handled" and skips it → unpinned exactly once.

Why it's safe

• Only paraheads reads this value (the unpin guard); runtime_service ignores it (|(_, b, _)|) and uses the separate InputIterItem::async_op_user_data, which is unchanged.
• The one case that could turn this into a pin leak (a block becoming Finished via same_async_op_as_parent without going through async_op_finished) is structurally impossible in paraheads — all inserts pass same_async_op_as_parent = false.

Changes

• Fix in try_advance_output.
• Regression test in async_tree covering the finished-but-unreported pruned block.
• Doc clarification distinguishing the two async-op Options ("finished" in pruned_blocks vs "reported" in InputIterItem).