Absolute parent slots and diamond rejection prevent reusing OZ upgradeable parents across inheritance chains

Parent storage slots are absolute (documented for mixins in docs/MODIFIERS_AND_INHERITANCE.md), so one verity_contract OwnableUpgradeable with _owner : Address := slot 101 cannot be reused by a second inheritance chain where solc places _owner at slot 51. Pareto has exactly that: IdleCDOEpochVariant is IdleCDOCreditVault is PausableUpgradeable, GuardedLaunchUpgradable(Initializable, OwnableUpgradeable, ReentrancyGuardUpgradeable), IdleCDOStorage puts _owner at 101, while IdleCreditVault is Initializable, OwnableUpgradeable, ERC20Upgradeable, ReentrancyGuardUpgradeable puts it at 51.

In addition, the Solidity diamonds are rejected by design (diamond inheritance: ancestor 'Initializable' is reached twice): every OZ upgradeable parent inherits Initializable (and ContextUpgradeable), so a faithful parent list cannot be written; one has to pick a single parent per chain to carry Initializable/Context.

Workaround in the closure repo: the OZ parents are duplicated per chain in two namespaces (Source.Cdo.OwnableUpgradeable at slot 101, Source.Strategy.OwnableUpgradeable at slot 51), and Context/Initializable are attached to one parent each.

Ask: (a) slot rebasing for is parents (e.g. is A @ 101 or a per-chain base), or a linearization-derived automatic layout for storage-parents; (b) tolerate diamonds whose repeated ancestor contributes no storage and no conflicting functions (the OZ Initializable/Context case).

Closure-side tracking: audit/VERITY-GAPS.md G7.

Start with docs/MODIFIERS_AND_INHERITANCE.md to understand the documented absolute parent-slot behavior, then review audit/VERITY-GAPS.md entry G7 and the described inheritance chains. Compare the two workaround namespaces and determine how slot rebasing or automatic layout could address them, while preserving safe repeated ancestors. Done means the supported behavior and diamond rules are defined and covered by appropriate verification.