Renewing a CSRF token (as reported by the client) upon reauthenticating

Renewing a CSRF token (as reported by the client) upon reauthenticating

Relevant (unanswered) questions I've asked on StackOverflow:

• https://stackoverflow.com/questions/70703895/securely-renewing-a-session-without-javascript-and-without-breaking-csrf-protect
• https://stackoverflow.com/questions/70713661/is-it-a-security-concern-to-allow-a-client-to-generate-a-csrf-token-at-login-tim

For reference, I am working in a legacy application, that also must work on browsers with JavaScript disabled, so between those two constraints the easier/better solutions to this problem are unavailable to me. However, I am trying to evaluate if the following solution provides adequate security (understanding that the user experience is less than ideal).

First the problem. This application involves filling out large web forms, which often take the users a significant amount of time. During this time, a user's session may expire and the user loses their work. A mechanism is needed to allow users to renew their session prior to submitting the form. See my linked questions for more detail.

The solution I have come up with, which I am questioning the security of, is as follows:

1. The user logs in as normal and begins filling out a form
2. Users without JavaScript see a message indicating when their session is set to expire, with a button that will open a login page in a new tab to allow them to renew their session before clicking the form's submit button.
3. The user's session expires. Since the CSRF token is associated with the session, the CSRF token is now also invalid.
4. The user clicks the "renew session" button, which opens a new tab with a login page. The user's now-invalid CSRF token is also forwarded to the login page.
5. The client sends their username and password (along with the old invalid CSRF token in a hidden field) to the server.
6. The server checks the username and password. If they are valid, the server re-associates that CSRF token with the user's new session, making the token valid again.
7. The user submits their original form (which has the original CSRF token as a hidden field). The server sees that the CSRF token matches the one given by the client at login, and accepts the form submission.
8. The server issues a new CSRF token to use on the next request.

Put more simply, if the server receives a string controlled by the client during the user's initial authentication, alongside the user's username and password, is it safe for the server to treat that string as a valid CSRF token for a subsequent request from that same client? Or is there a way that this could be exploited?

It seems to me that, considering the request which sets the CSRF token is only accepted if accompanied by a valid username and password, it should still prevent CSRF. After all, if an attacker has that information, they have already compromised security. However, there may be things I have not considered; hence this question.