Fix footnotes's subscript numbering on para delete and undone

[USERSATOSHI]

What?

Closes #60050

This PR fixes the footnote numbers being incorrect when paragraphs are deleted and undone.

Why?

Currently when we delete paragraph containing the footnote and undo it the numbering on subscript gets broken

Example

Para1: Hello World[^1]
Para2: Ok Bye[^2]

delete Para1 and undo it

Para1: Hello World[^1]
Para2: Ok Bye[^1]

How?

This PR fixes this by updating useEntityBlockEditor to check if blocks contain footnotes and if it does then update the blocks to match current footnotes.

Testing Instructions

1. Set footnotes for each of several paragraphs.
2. Delete the first paragraph.
3. Undo.

Screenshots or screencast

Screen.Recording.2025-07-25.at.8.43.47.PM.mov

[Mamaduka]

@USERSATOSHI, the numbering seems to be working correctly - #60050 (comment).

[USERSATOSHI]

@USERSATOSHI, the numbering seems to be working correctly - #60050 (comment).

Hi I seem to still able to reproduce this issue

cc: @Mamaduka

[Mamaduka]

@USERSATOSHI, can you share your reproduction steps and maybe a screen recording in the issue?

[USERSATOSHI]

I was able to reproduce this via Following steps

1. Add footnotes to block, save and refresh
2. Add a new para , save as draft
3. then delete first footnote para.

Screen.Recording.2025-07-28.at.1.02.48.PM.mov

cc: @Mamaduka

EDIT: Formatting.

[USERSATOSHI]

Was also able to get this only works if adding and deleting is done without saving first

Steps:

1. Add Paras, Save and refresh
2. Add footnotes to both paragraphs. ( Dont save it )
3. Delete Footnote of first para

Screen.Recording.2025-07-28.at.1.12.04.PM.mov

cc: @Mamaduka

EDIT: Formatting

[Mamaduka]

Okay, I can reproduce it, but it's not very consistent. The only consistent way I found was to add an empty paragraph after the Footnotes block, then delete and undo the change.

I think this suggests that a more subtle bug is at play. It would be great to track down exactly why this is happening and create an end-to-end test that fails on the trunk but passes with the fix.

Screenshot

CleanShot.2025-07-28.at.11.53.15.mp4

[USERSATOSHI]

@Mamaduka , Saving the footnotes first doesn't cause issue.

it occurs when we save the para,
then add footnotes ( don't save it yet ) and delete the first one.

That is consistent to me.

Repro for this: comment

[Mamaduka]

What I wanted to say is that the bug has concrete steps to reproduce and doesn't always affect the footnotes.

Let's investigate why it's happening under those conditions and not otherwise, before we proceed.

[USERSATOSHI]

What I wanted to say is that the bug has concrete steps to reproduce and doesn't always affect the footnotes.

Let's investigate why it's happening under those conditions and not otherwise, before we proceed.

Got it, I will post my findings on the issue itself so others can also join in on the discussion.

cc: @Mamaduka