feat: tag events handlers partial recovery

[aintnostressin]

Prepares tag handlers for partial recovery.

• DEL handler: graph-last ordering — Reads tag target from graph first (new get_tag_target query), performs Redis index cleanup, then deletes the graph edge last. This ensures the TAGGED edge survives for retry if Redis ops fail mid-way.
• DEL handler: guarded decrements — Uses check_set_member to verify the tagger is still in the Redis set before decrementing counters/sending notifications, preventing double-decrement on retry.
• PUT handler: retry recovery — When put_to_graph returns Updated (edge already exists from a prior attempt), re-runs idempotent Redis index writes to recover from partial failures where graph succeeded but Redis didn't.
• Idempotent no-op on replay — Tag DEL no longer returns SkipIndexing when the graph edge is already gone; it returns Ok(()) silently.

[ok300]

Suggested change

	let tagger_in_index =
	TagUser::check_set_member(&[tagged_id.as_str(), label.as_str()], &user_id)
	.await?
	.1;
	let (_, tagger_in_index) =
	TagUser::check_set_member(&[&tagged_id, &label], &user_id).await?;

[ok300]

Suggested change

	let tagger_in_index = TagPost::check_set_member(
	&[author_id.as_str(), post_id.as_str(), label.as_str()],
	&user_id,
	)
	.await?
	.1;
	let (_, tagger_in_index) =
	TagPost::check_set_member(&[&author_id, &post_id, &label], &user_id).await?;

[ok300]

This is almost identical (1 line diff) to delete_tag in del.rs. This means any future logic change in the query has to reflect equally across both methods.

Maybe there's a way to avoid query duplication? Like have both methods internally use the same "query builder fn" with one boolean flag include_delete_call?

Alternatively, both methods should have a comment pointing at each other, saying "query logic must be kept in-sync with (other fn)". Although this is more error prone than the 1st suggestion.

[ok300]

Maybe this shouldn't panic, but instead throw a GraphError?