Safe confirmation depth on Polygon PoS before treating a transaction as final

Goal

I am designing a backend service that triggers an off-chain action (releasing a digital asset) once a payment transaction is observed on Polygon PoS. I want to avoid acting on a transaction that a later reorg removes, since the action cannot be undone once taken publicly.

Constraint and uncertainty

My understanding is that Bor produces blocks roughly every two seconds, but real finality comes from Heimdall checkpoints committed to Ethereum, so a transaction with only one or two confirmations could still be reverted. Documentation and community guidance seem to differ on how many confirmations are "enough," and the answer likely depends on the value at risk. I am targeting the current Polygon PoS mainnet (not zkEVM), and I can tolerate a delay of a few minutes before acting.

Questions

1. Is waiting for inclusion in a Heimdall checkpoint the only way to get deterministic finality on Polygon PoS, or is there a documented block depth considered safe for high-value actions?
2. Does the recommended confirmation count differ between simple POL/ERC-20 transfers and contract interactions with dependent state?
3. Is there a canonical RPC or explorer field to check whether a given block has been checkpointed?