opt: relex scenario to set distrustFK to true

In https://github.com/cockroachlabs/cockroach/pull/4662 we introduced the eval.Context.DistrustFKs() method, which returns true whenever
the txn is in defer mode, i.e. the session variable was on when the txn started, whether or not any fk check has actually been deferred yet. So today the question asked is "is this txn in defer mode", not "has anything been deferred". While it's true, every stmt in the txn is planned ignoring all fk constraints, so it loses join elimination / fk-derived filters and its plans are kept out of the query cache.

This might be overly strict and could hurt the performance of queries who touches fks that are not deferred at all. @DrewKimball proposed easing the restriction:

The main query doesn't read its own writes or those of routines that it executes to avoid the halloween problem. So we should be able to check whether any FK checks were deferred at planning time in order to decide whether the FKs are valid. Volatile routines, cascades, normal checks, and triggers on the other hand, probably do need to plan as if any FK could be invalidated when this setting is true.

Some addition:

• distrustFK should cover everything that runs inside a volatile routine / cascades / triggers /checks, not just themselves. E.g. A STABLE routine called from a volatile one sees the volatile one's earlier writes, and its plan is built once and reused.
• Pausable portals have their plan living beyond their planning moment and doesn't go through staleness check when reinvoked. We should probably be defensive here.

Jira issue: CRDB-68513

Start with eval.Context.DistrustFKs(), introduced in PR 4662, and trace where it affects planning and query-cache decisions. Work through deferred checks, volatile routines, cascades, triggers, checks, and pausable portals; done means FK-derived planning is retained only when safe while nested execution and long-lived plans remain defensive.