In my experience, the simple answer is "no" - but I'd appreciate confirmation.
Client-side, I use the Firestore Client SDK and Firestore rules to manage my Firestore database. This works fine.
Server-side, I can continue to use the Firestore Client SDK but all read/write requests are rejected here if meaningful Firestore rules are present (ie anything other than "allow read, write"). This behaviour persists even after logging a user in on the client, passing a uID to an authorised server, and decoding it.
The alternative is to forget about Firestore rules, authenticate the server code with a service account and manage authenticate database use in code rather than through Firestore rules.
This too works fine but niggles because I'm now doing the same thing in two different ways. It appears that server-side you have to re-interpret your Firestore rules in code and accept the need to use Firestore Admin SDK database commands rather than Client SDK commands. Firestore rules aren't supported here and attempts to use them trigger errors.
Am I missing something?
It appears that server-side you have to re-interpret your Firestore rules in code and accept the need to use Firestore Admin SDK database commands rather than Client SDK commands.
Yes, this is the way things work. Security rules are necessary for client code because the client can be compromised or malicious in some way - you just don't control the way the code executes. This isn't a problem on backends where you are in full control, so your code can be trusted to do the right thing.