test: add receive two-session lock harness

[alceops]

Adds an optional two-session psql harness for the same-consumer pgque.receive() race discussed in #125.

The existing SQL regression coverage is single-session, so this script opens two real backend sessions:

• session 1 receives one message and holds the transaction open
• session 2 concurrently calls pgque.receive() for the same (queue, consumer)
• the harness expects session 2 to wait on the row lock and return zero duplicate rows

I left it as an explicit script instead of wiring it into CI because it is meant as a red/green validator for the held #125 fix: current pre-fix code fails, while the row-lock fix should make it pass.

Verification run locally against current main install (expected red):

bash -n tests/two_session_receive_lock.sh
PGQUE_TEST_DSN=postgresql://postgres:***@localhost/pgque_test tests/two_session_receive_lock.sh
# FAIL: two-session receive harness failed (session1=0, session2=3)
# session2 waited ~3.2s, then received 1 duplicate row

[NikolayS]

thanks @alceops!! left some comments above

[NikolayS]

Follow-up status for #175:

• test: add receive two-session lock harness #175 was merged to add the standalone two-session receive harness before the 0.2 release.
• test: synchronize two-session receive lock harness #220 fixed harness synchronization. The original version polled sub_batch, but that state is uncommitted while session 1 holds the transaction, so session 2 could start only after the lock was released. The fixed harness waits for session 1 to be inside pg_sleep() via pg_stat_activity before starting session 2.
• [ON HOLD v0.2.1] fix(pgque.receive): prevent double-delivery on concurrent same-consumer calls #125 has now been rebased on current main and wires this harness into CI as the RED/GREEN proof for the same-consumer receive-lock fix.

Thanks @alceops for the original harness contribution.