v2.16.0

Changed

• One revive trigger per owner table (#70, ADR 0033). Since 2.11.0 every cascade key carried its own statement-level revive trigger on the owner table, each running a full UPDATE … FROM join over the transition tables on every UPDATE of that table: one consumer table had 16. The generator now emits one trigger and function per owner, soft_delete_revive_on_<owner>, with every key's revive as an arm, joined forms included, behind one test of whether the statement revived a row at all. On 16 keys scripts/bench_revive.py measures +0.245 ms an UPDATE per key against +0.047 ms per owner. Upgrade step: makemigrations (or makeguitarmigrations) emits one migration in each app hosting an owner that retires every per-key revive whose key still cascades, IF EXISTS over every spelling its tables held, and creates the per-owner triggers; --check fails until it is generated. Its reverse rebuilds the per-key triggers.
• A child table dropped without its retirement (#63) now breaks only an UPDATE that revives a row of the owner, where it broke every UPDATE. Quieter, so keep makemigrations --check in CI: deleting the child's model moves the owner trigger's digest, and --check in a run including the trigger's host app fails until the trigger is regenerated without that arm. A run scoped away from that app names the trigger.
• An MTI parent and its child both keyed from one model no longer clash on a revive name: their revives are two arms of one function. The cascade rule clash on that shape is unchanged.

Added

• scripts/bench_revive.py, timing a single-row UPDATE with N keys' revives per key and per owner. Not run in CI.