Enforce a minimum delay for FWSS and PDPVerifier contract upgrades

## Summary

Add a contract-enforced minimum delay between announcing and executing upgrades to the FWSS and PDPVerifier contracts.

The FOC WG considered doing this as part of #505 / #533 and decided on 2026-06-30 **not to prioritize contract-enforced delay now**. For the immediate work, we will keep #505 focused on contract/operator ergonomics. This issue preserves the security-hardening work as an explicit backlog item for future prioritization.

Decision record and trade-off analysis: [202606 Contract upgrade delay decision: FWSS and PDPVerifier](https://app.notion.com/p/filecoindev/202606-Contract-upgrade-delay-decision-FWSS-and-PDPVerifier-38bdc41950c18080be5bfe1179b53a81)

## Why

A contract-enforced delay provides a verifiable security guarantee that process alone cannot provide. It gives operators and integrators time to inspect an announced implementation and react to deployment mistakes, malicious upgrades, or a compromised/social-engineered multisig before the new implementation can execute.

We are deferring it because current customer demand is limited, FOC still expects meaningful contract iteration, and the delay would constrain operational response. We should revisit that balance as adoption, funds at risk, and demand for trust minimization grow.

## Direction discussed

The leading future shape discussed was:

- Apply to both FWSS and PDPVerifier.
- Use a simple ramp that reaches approximately 48 hours after a period of stability, rather than the original two-week maximum proposed in #533.
- Keep the policy understandable and easy to communicate.
- Do not assume that rollback can always bypass the delay; rollback may be storage-unsafe.
- Preserve the ability to tighten the delay over time without needing to weaken an already-promised security guarantee.

The exact curve, grace period, and implementation remain to be decided when this is prioritized.

## Done criteria

- [ ] Confirm the current customer/integrator requirement and threat model.
- [ ] Decide the delay shape, ramp period, and maximum delay.
- [ ] Define behavior for emergency fixes and rollbacks.
- [ ] Implement the policy for both FWSS and PDPVerifier.
- [ ] Emit sufficient event data for operators and monitoring systems to determine the earliest execution epoch.
- [ ] Add contract tests, deployment/tooling support, and operator documentation.
- [ ] Coordinate with [FilOzone/tpm-utils#51](https://github.com/FilOzone/tpm-utils/issues/51) so upgrade announcements are surfaced in Slack. This monitoring improves transparency but does not itself provide a security guarantee.

## Related

- #505
- #533
- [FilOzone/tpm-utils#51](https://github.com/FilOzone/tpm-utils/issues/51)

Start by reviewing the FWSS and PDPVerifier contract implementations, the decision record, and related issues #505 and #533. Confirm the customer requirement and threat model before deciding the delay curve, grace period, emergency and rollback behavior. Done includes both contract implementations, event data, tests, deployment/tooling support, operator documentation, and coordination with tpm-utils#51.

Written by the indexing model from the issue text.