Accuser operations error at migration

One can observe that running

dune exec tezt/tests/main.exe -- --file double_consensus.ml --verbose --title 'double attestation using wrong slot under migration from r022 to alpha'

(on !17905 (merged))

(or any other tezt with a migration from r022 to alpha) succeeds, but the accuser from the old protocol keeps verifying the operations even after the protocol migration occurs. For migration from quebec to r022, this does not have any issue, but from r022 to alpha, we get something like:

[10:23:26.972] [accuser1] May 01 11:23:26.972: 022-PsRiotum: error while baking:
[10:23:26.972] [accuser1] May 01 11:23:26.972:   Rpc request failed:
[10:23:26.972] [accuser1] May 01 11:23:26.972:      - meth: GET
[10:23:26.972] [accuser1] May 01 11:23:26.972:      - uri: http://127.0.0.1:56798/chains/main/blocks/head/helpers/validators?level=9
[10:23:26.972] [accuser1] May 01 11:23:26.972:      - error: Failed to parse the answer (application/octet-stream):
[10:23:26.972] [accuser1] May 01 11:23:26.972:                 error:
[10:23:26.972] [accuser1] May 01 11:23:26.972:                   Failed to parse binary data: Unexpected tag 9.
[10:23:26.972] [accuser1] May 01 11:23:26.972:                 content:
[10:23:26.973] [accuser1] May 01 11:23:26.972:                   "\000\000\003\003\000\000\002\255\000\000\000\t\000\231g\0152\003\129\007\165\154+\
...

The issue comes from the change of the encoding from !17703 (merged).

The cause is that the old accuser continues monitoring operations from the next protocol, as can be seen in the worker_loop from client_baking_denunciation.

This is discussed as well on Slack.