The client is using Active Directory (AD) as a central authentication. As such, there should be no password policy configuration on either Linux or Windows clients. That should go only on the AD.
internally, Linux and Windows complexity and timeout settings are different.
Kind of agree, if we were talking about local accounts (which we are not).
If they set the Linux password complexity/timeout settings, then there is potential that the Linux system will ask for a password change before Windows AD will
The AD stores the time of the last password change for the account. The AD global object stores the number of days (well, microseconds) after which the passwords expire.
So, the actual time when the passwords expire is known to both Windows and Linux ()and it's enforced by the AD, anyway). You might have Windows encouraging you to change your passwords since -made up numbers- 7 days before expiration and Linux only from 5 before (which you can ignore), but that's not what is being stated here, and isn't that relevant.
Moreover, if the password was changed earlier than required, that's perfectly fine, too. That resets the password expiry, it doesn't matter if there were 3 days left or 30. So I don't see why that would be a problem, either.
Linux password complexity will be different to Windows complexity and the user will change their password to something that is valid in Linux, but is not valid in Windows and therefore gets locked out their account
No. When you change the AD password from Linux (eg. with smbpasswd, but passwd may be hooked to do the network password change), it sends the old and new passwords to the AD. It is therefore the AD the one that needs to accept it.
It is true that you may easily set some passwords from Linux that are not (easily) usable from Windows due to different keyboard settings (you could set the password a character that you can't type from Windows login screen, oops!), but Windows itself would be happy to accept it (as shown for instance when providing it through RDP). But that would be completely unrelated to complexity rules.
Also note that should you end up in such a situation, you can go back and change the password from Linux to something accepted and typable from Windows.
Is this true? Can't they just set up the password settings of OS and AD the same way (i.e account lockout, idle session timeout, complexity) to avoid this?
You are mixing a few different values. Idle session timeout would be indeed a local configuration. But the password settings wouldn't be handled locally (in nsswitch terms, by the passwd/compat provider) but from the AD, where most settings are configured and stored, and which is enforcing the status of the different accounts (if there were too many bad password attempts, the AD will refuse a bind with those credentials, no matter if the client verifies itself the badPwdCount or not¹).
¹ Exception: if a program was manually checking the provided password against the password hash, it would need to do itself all those AD checks. I don't consider it a good practice when the AD can do it for you, though, and you would probably need to go out of your way in order to have the AD disclose the password hash to the application.
It could be that the client is actually using separate accounts. An AD from which Windows clients authenticate, and local accounts in Linux. Then, some of the above confusion could happen. But they would actually be different accounts! (even if they use the same username, and have users normally change the passwords at the same time) In that case, the right thing would be to integrate the Linux clients in the AD, instead of using separate accounts. It is more complex to setup than creating local unconnected users, and most Linux users -not being on a corporate environment- usually don't go that route, but it's perfectly doable and on an environment such as the described one it's the right move.