Summary:
**What is the issue?**

A session can set `yb_read_time` and use `LISTEN`/`NOTIFY`, even though they assume different views of the database.
- Time-traveled reads only see data as of the chosen timestamp.
- `NOTIFY` delivers signals about live activity that may not match that snapshot.
- An application cannot rely on both in the same session without ambiguous or inconsistent behavior.

**What needs fixing?**
We reject incompatible combinations in these cases:
- `LISTEN` fails when `yb_read_time` is already non-zero (autocommit or inside a transaction).
- Setting `yb_read_time` to a non-zero value fails while `LISTEN` is active or pending in the session (autocommit or inside a transaction).
- Setting `yb_read_time` to a non-zero value fails after a `LISTEN` in a committed subtransaction.
`SET yb_read_time TO 0` remains allowed while listening.

**How are we fixing it?**
- Add `ybRejectListenInTimeTravelSession()` at `Async_Listen` and `Exec_ListenPreCommit`.
- Add `YbHasActiveListen()` to detect active channels and pending `LISTEN` actions in the current transaction.
- Check `YbHasActiveListen()` in `check_yb_read_time` and `assign_yb_read_time` when setting a non-zero value.
- Add Java integration test `testDisallowListenWithYbReadTime` in `TestPgListenNotify`.

Fixes [[ https://github.com/yugabyte/yugabyte-db/issues/31481 | #31481 ]]
Backport-through: 2025.2

Test Plan: ```./yb_build.sh release --java-test 'org.yb.pgsql.TestPgListenNotify'```

Reviewers: aagrawal

Reviewed By: aagrawal

Subscribers: mhaddad, yql

Differential Revision: https://phorge.dev.yugabyte.com/D54480