[Vinz2168]

The opt-in for the new login page (ReCasaOS/CasaOS#84, point 2). The login page has no session to read a user's settings with, so the choice belongs to the box. The user service keeps it and tells it to anybody:

• GET /v1/users/status also returns login_style: "classic" or "beta". The login page already calls it before anybody signs in.
• PUT /v1/users/login-style with {"style": "classic"} or {"style": "beta"} changes it. It needs a session, like every other setting. Any other value gets a 400 (4000).
• The choice is kept in its own file, login-style, in the user data folder (/var/lib/casaos). The file is written next to its place and then renamed, so a reader never sees half a file. classic removes the file, so a box that never chose stays as it was. A file that can't be read, or holds anything else, also means classic.

The UI side is ReCasaOS/CasaOS-UI#123.

Tested: route/login_style_test.go (status without a session; PUT without a session gets 401; bad values; beta, then classic, then classic again; a file with something else in it), and the whole go test ./.... On a Mint box (v0.5.84) with this build: status says classic, the PUT turns it to beta, and the UI PR shows the new page.

[inkly]

Looks good. The PUT sits in the JWT-protected v1 group, the value is whitelisted on both sides, and the file path never takes user input. An old UserService with the new UI falls back to the classic page.

Two small things, non-blocking:

• route/login_style_test.go: config.AppInfo.UserDataPath = t.TempDir() is never restored, so later tests in the package point at a deleted folder. The other tests use t.Cleanup for this (v1_password_test.go, first_admin_test.go).
• setLoginStyle: the temp file name .new is fixed, so two PUTs at the same moment race and the second Rename returns a 500 that shows the path. os.CreateTemp in the same folder avoids it.