Good to see a write up that covers the parts that usually bite later, such as connection pooling and setting the tenant context per transaction rather than per session.

One practice I would add: make cross tenant access tests part of the definition of done for every feature that touches tenant data. A small suite that logs in as tenant A and tries to read, update and export tenant B's records catches the cases where a new view or a background job quietly bypasses the policy. Those tests are cheap to write and they turn row level security from a configuration you trust into a property you verify on each deploy.

It also makes security reviews with customers much easier, because you can show the tests rather than describe the intent. Do you run background jobs under a separate role with its own policies, or do they set the tenant context the same way requests do?