fix: roll back subscriber transaction on nack

[Yuki9814]

Motivation / Background

When a SQL subscriber receives a Nack, it currently keeps resending inside the same query transaction. That leaves the selected row locked to one consumer and prevents another subscriber in the same consumer group from picking it up.

Addresses ThreeDotsLabs/watermill#224.

Details

• Return a private Nack signal from message delivery so the existing query error path rolls back the transaction.
• Preserve ResendInterval as the delay before the current subscriber queries again, giving peers a chance to acquire the message.
• Add a focused transaction regression test that asserts Nack rolls back rather than commits.

Alternative approaches considered (if applicable)

I considered rolling back directly inside sendMessage, but keeping transaction lifecycle in query avoids coupling message delivery to the transaction implementation and reuses the existing rollback handling.

Checklist

• I wrote tests for the changes.
• The focused regression test passed 50 consecutive runs.
• The focused race test passed 50 consecutive runs.
• All packages compile and go vet ./... passes.
• The database-backed suite could not run locally because this machine has no container runtime; repository CI remains the integration gate.
• Code has no breaking changes.
• Documentation changes are not applicable.