Speculation:
This behavior could be explained if the policy proto contains an empty login_screen_input_methods list, and the input method restriction leaks to the user session.

--
Empty login_screen_input_methods:
We should be checking for empty list here:
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/lock_screen_utils.cc?type=cs&sq=package:chromium&l=98
Instead of relying only on the presence of the setting to decide if we should apply input method restrictions.

If this is the case, a fast workaround would be change the server-side settings not to send down this field in the proto (investigating)

--
Leaking to user session:
This should _not_ happen. Currently investigating.
Possibly related to multi-profile mode or to invocations of EnforcePolicyInputMethods from ViewsScreenLocker, if these reached the version mentioned above.

Confirmed that the server is sending down an empty login_screen_input_methods list.

I was able to reproduce the issue with:
(1) Login with primary profile
(2) Login with secondary profile
(3) Ensure you're in secondary profile
(4) Lock screen
(5) Unlock screen, now you'll be in primary profile automatically
    but input methods will be from secondary profile
(6) Switch to secondary profile
(7) Switch to primary profile

Now, input methods are restricted by policy.

Further investigation revealed that the sequence of events is:

Precondition: Secondary account is active, user goes to lock screen
There are two IME States: IME_state_primary, IME_state_secondary.
active == IME_state_secondary.

(1) lock screen handling code is entered
(2) lock screen handling creates new IME_state_lock
(3) saved = active (which is IME_state_secondary)
(4) active = IME_state_lock [1]
(5) active = IME_state_primary [2]
(6) policy enforcement code runs [3], modifies active == IME_state_primary
(7) lock screen exits, returns to saved, so
    active = IME_state_secondary
(8) user changes to secondary profile and back
    active = IME_state_primary which still has restrictions on it activated in (6).

So, (5) should not have the consequence of leaving the user's IME state active on the lock screen.

[1] Creating of lock screen's IME state and setting it as active:
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/lock/screen_locker.cc?rcl=3526d3a7f45d3c25fdffac894ab5d0c501b087c2&l=207

[2] Setting primary user's IME state as active while on the lock screen:
SigninScreenHandler::HandleFocusPod is called on lock screen load, which calls SessionControllerClient::DoSwitchActiveUser on focusing already-logged in users.
This ends up in UserSessionManager::ActiveUserChanged, which activates that user's IME state.

[3] Enforcing policy restrictions:
https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/chromeos/login/signin_screen_handler.cc?l=1598
called from
https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/chromeos/login/signin_screen_handler.cc?l=235

Other points to consider:
- Consider only enforcing policy-set input methods on IME state specifically created for sign-in/lock screen (not simply on "active IME state")
- Check if ViewsScreenLocker (in construction) is using EnforcePolicyInputMethods / StopEnforcingPolicyInputMethods correctly.