Fix oversight in FindTriggerIncompatibleWithInheritance.

[anonymou0719]

Summary

This PR syncs a commit from a fork into this repo to fix an inheritance/partitioning trigger-compatibility false positive: the compatibility scan previously treated statement-level triggers with transition tables as if they were row-level, which could incorrectly block ATTACH PARTITION / inheritance operations.

Original commit

URL: https://github.com/percona/postgres/commit/220f1c0b80ccb9de7da99d6d24775c74bdbc6a1d

What it does: Ensures the trigger inheritance compatibility check only considers row-level triggers with transition tables, skipping statement-level triggers so valid tables are not incorrectly rejected for partitioning/inheritance.

Why it fits this repo’s guidelines/policies

Correctness / bug fix: Fixes overly-restrictive behavior in inheritance/partition attach checks without changing intended semantics for row-level triggers.

Minimal & localized: Touches only the trigger compatibility scan used by ATExecAttachPartition/ATExecAddInherit, reducing risk of unintended side effects.

Backward compatible: Does not change user-visible behavior except removing an incorrect rejection in a narrow edge case.

Notes (adaptations, if any): Ported cleanly; no functional deviations intended from the source commit, aside from any repo-local context/paths.

Why it’s useful here

Benefit: Bug fix for partitioning/inheritance operations where statement-level triggers with transition tables were incorrectly treated as incompatible.

Impact: Reduces false positives and avoids needless blocking of valid schema operations; improves usability for users relying on statement-level triggers with transition tables.

Testing

Existing tests: ✅ make check triggers (pass)

CI link (if any): N/A

Extra tests (if any): None beyond regression coverage noted above.