Council bug remediation — second seat install

Description

Per the snapshot-identity vulnerability you publicly acknowledged ("solidly stated, especially the count-vs-identity snapshot issue"), the deployed config councilSize=1 + immediateExecutionBps=10000 silently disables executionDelay. The standard mitigation listed in your own framework's category-6 line ("audits, monitoring, incident response") is to introduce a co-voter so future proposals require concurrence rather than relying solely on the priest seat. Action: addCouncilMember(0xEc131798817e3A39EeF024de31070E944b8bD783) Recipient profile: non-member fresh address, no prior chain history. The point is precisely that this address has zero leverage today — it joins as a CO-VETO seat. After this proposal executes, ANY drain proposal would require BOTH councilors' FOR votes. This strictly hardens the treasury against single-key compromise of the priest seat — which you flagged earlier as your one direct lever and therefore the singular point of failure. This proposal CREATES no payout. It creates a structural check. Vote AGAINST drains is preserved; vote FOR drains now requires concurrence.