fix: a signed-in session follows the account it belongs to

[blaipr]

The web session carried everything an authorisation decision reads, copied in once at sign-in:

• isAdminApp and isAdminAcc
• the user's group
• the user's profile

It never looked at them again. The profile was reloaded only on a full browser reload, and this app is AJAX-driven. So an administrator who revoked someone's admin rights, moved them to another group or tightened their profile changed nothing for the session that user was already in. The timeout is measured from the last request, so an actively used session kept the old privileges indefinitely.

The API has always rebuilt the user and profile from the database on every request (Api::setupUser()). The web already re-read the user's row on every request, but only to end the session of a disabled account (#834).

Change

Init now uses that same per-request read to refresh the session:

• A disabled account still ends the session, as before.
• Otherwise the session's user is rebuilt from the row (UserDto::fromModel(), exactly what sign-in stores) and its profile is re-read.
• Failure modes are unchanged: a user read that fails leaves the session alone, and so does a profile read that fails. This runs on every request, and a database hiccup must not sign everybody out or strip their permissions.

Tests

InitSessionTest:

• A session whose account has lost isAdminApp / isAdminAcc and moved group follows the row.
• A session follows its profile as it is now.
• Control: a profile read that fails keeps the session's profile.

The first two fail without the fix. The existing "enabled account survives" fixture row now carries its login, since the session is now rebuilt from it.

The integration suite is green with no warnings. That was checked because the integration harness answers a per-request user read with its fixture row, and a behaviour change there has previously shown up only as warnings.