A policy whose plugin is missing is silently skipped, so a limit fails open

ConstraintPolicyManager, in the method that collects a line's attachments, keeps a policy only when the manager can define its plugin id, and says nothing when it cannot. So renaming a ConstraintPolicy plugin id disarms every attachment already stored against the old id: the rows are still there, the policy tab still lists them, and nothing asks them. A limit that vanishes this way oversells, which is the one outcome a limit exists to prevent. This happened between two releases of this project, and it presented as a model regression rather than as stale data.

Proposed: log the host entity type, its id and the unknown plugin id, so a stale attachment announces itself rather than failing open. Worth deciding whether a limit whose plugin is missing should refuse the hold instead of being skipped, since failing closed is the safe direction for a cap. The test has to attach a policy whose plugin id does not resolve, and be seen to fail first.

This is independent of the declaration model: whatever a policy declares, an unresolvable plugin id must not silently vanish, which is why it is worth fixing before that redesign. The two other faults reported here originally (a single hold running no policies, and surfaces entering through different doors) moved to #3614532: Constraint policies should declare what they need rather than when they run, and stop assuming a tariff, where the checkpoint design settles them.