[FLINK-40521][network] Document potential lost priority-barrier wakeup in LocalInputChannel during checkpointing-during-recovery

[1996fanrui]

What is the purpose of the change

In LocalInputChannel, hasPendingPriorityEvent is set lock-free in notifyPriorityEvent() and cleared
lock-free in pullPriorityFromSubpartitionView() on a stale snapshot, which is a latent lost-wakeup race.
It is currently safe because Flink runs no concurrent unaligned checkpoints, so at most one priority barrier
is ever pending. This documents the race and why it is safe today, rather than changing the logic.

Brief change log

• [FLINK-40521] Add a comment in LocalInputChannel#pullPriorityFromSubpartitionView describing the latent lost-wakeup race and why it is currently safe.

Verifying this change

This change is a trivial rework / code cleanup without any test coverage (comment only, no behavior change).

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

[flinkbot]

CI report:

• 1db4690 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build