RE: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation

Hi Alexander,

> It took 3 months for buildfarm animals to discover an instability of the
> fixed test:

Good catch!

> I can reproduce this reliably with a simple sleep:

I could also reproduce the same.

I found lines [1] in the publisher log, this meant that registering the point failed
because it has already been registered. Per my research, injection points which
are set as local one can also be registered on the shared memory and same local
injection points cannot be registered at the same time. set_local ensures that
the point is enabled for the specific backend and can be removed after the backend
exits. Based on that, below event can happen in the 051 test:

1. a backend registers an injection point 'logical-decoding-activation' at line 480.
2. the test runner finishes the client for the backend at line 500.
The backend will eventually clean up the injection point, but the runner can
go ahead without any waits.
3. the runner starts a new session immediately and tries to register the injection point.
It could fail of the previous backend has not cleaned up yet.
4. The session can continue because on_error_stop is 0.
It calls pg_create_logical_replication_slot() but cannot stop the injection
point because the process does not attach.

My brief fix idea is to expressly wait until the injection point is cleaned up. See attached.

[1]
```
2026-10-30 03:38:57.014 CET [626716][client backend][3/6:0] LOG: statement: select injection_points_set_local();
2026-10-30 03:38:57.018 CET [626716][client backend][3/7:0] LOG: statement: select injection_points_attach('logical-decoding-activation', 'wait');
2026-10-30 03:38:57.018 CET [626716][client backend][3/7:0] ERROR: injection point "logical-decoding-activation" already defined
2026-10-30 03:38:57.018 CET [626716][client backend][3/7:0] STATEMENT: select injection_points_attach('logical-decoding-activation', 'wait');
```
Best regards,
Hayato Kuroda
FUJITSU LIMITED