Merge main into release/v3.x-new in order to prepare for v3.6.18 release

[arlai-mk]

Description

Brings main into release/v3.x-new for the v3.6.18 release, per RELEASE_PROCESS.md (same as #452 for v3.6.17). It carries #453, #454 and the release preparation #455.

Merge with "Create a merge commit", not "Squash and merge", so the release branch keeps the history and can be reused for future releases.

After the merge: create the tag v3.6.18 from release/v3.x-new and publish the GitHub release.

[claude]

Review: v3.6.18 release merge (main into release/v3.x-new)

This brings #453, #454 and the release prep #455 into the release branch. I reviewed the non-artifact changes. I did not rebuild the wasm artifacts or run the test suites.

Release hygiene

• ✅ Workspace version is 3.6.18 in Cargo.toml and Cargo.lock.
• ✅ The .changelog/v3.6.18/ entries and summary.md match the CHANGELOG section.
• ✅ Schemas and artifacts/checksums.txt are updated.
• Please confirm the artifacts come from a fresh make compile at the merge head. The wasm diffs can't be reviewed here.
• Merge with "Create a merge commit", as the description says.

Control center (#454, contract.rs)

• ✅ The high-water mark (HWM) is now total_pool_value / (total_shares_issued + shares_to_mint). This is the post-mint price. It is saved only after the dust check, so dust still accumulates across accruals.
• ✅ The checked_add avoids overflow, and the new high_water_mark_price attribute is emitted from both accrue_fees and submit_deployed_amount.
• ✅ The tests in testing_fees.rs have the arithmetic worked out in comments (1100/1018).
• Suggestion: the Rust control center has no counterpart to the EVM resetHighWaterMark(). A deployed control center that already holds a pre-fix HWM above its share price will still have to re-earn that dilution once. If that is intended, add a line to the changelog. If not, a migration that clamps the HWM to the current price would fix it.

EVM vault (#453, InflowVault.sol)

• ✅ The HWM is now assets.mulDiv(WAD, supply + sharesToMint, Floor), which matches the Rust side. FeesAccrued.sharePrice is documented as the pre-mint price, and the changelog warns integrators about this.
• ✅ resetHighWaterMark() is whitelist-gated and uses reinitializer(2). It only lowers the mark and treats an empty vault as priced at WAD.
• ✅ initialize() now goes straight to version 2. onlyUninitialized stops it from being called on an already initialized v1 proxy.
• Note: onlyUninitialized runs before reinitializer. That ordering is correct. A reordering would silently reopen initialize() on v1 proxies, so keep a test that covers it.
• Note: resetHighWaterMark() uses up version 2 even when it is a no-op. This is documented, and it means a second reset is impossible. Make sure the upgrade is run with the intended state, ideally via upgradeToAndCall in the same transaction, as the script does.
• Rounding: Floor on both the share price and the HWM is consistent. The vault may sit up to 1 wei below its HWM after an accrual, which is harmless.

Upgrade script

• ✅ UpgradeInflowVaultResetHwm.s.sol defaults to a dry run and only broadcasts the implementation deployment when DEPLOY_IMPLEMENTATION=true and --broadcast are both set. It never touches the proxy itself.
• Operational note: the Safe signer must verify the printed calldata against a final IMPLEMENTATION address. A simulated implementation address is not safe to sign.

Test coverage

• ✅ New and updated Foundry tests cover the HWM and the fees (InflowVaultHighWaterMark.t.sol, InflowVaultFees.t.sol, and the InflowVaultV1 mock for the upgrade path). The Rust tests cover basic and consecutive accruals.
• Suggestion: add a Rust test where shares_to_mint rounds to zero, to check that the HWM is left unchanged on the new code path.

No blocking issues found. The main open question is the control center HWM for already deployed instances.