refactor!: add the XanV2Vesting recipients only through addRecipients

[heueristik]

This PR removes the recipients from XanV2Vesting.initialize. The council multisig, which owns the proxy, adds all recipients with addRecipients after the deployment. The deployment therefore no longer depends on the recipient list.

Contract and script:

• initialize(address initialOwner) sets the owner and emits VestingScheduled. The proxy starts without recipients.
• addRecipients holds the loop of the removed _addRecipients, which had no other caller.
• DeployXanV2Vesting.deploy(deployer) replaces deploy(deployer, recipients). readRecipients, RECIPIENTS_PATH, and ZeroRecipientsNotAllowed are removed.

Tests:

• The fixture adds its recipients through addRecipients as the owner, so the tests that use it start from the same state as before.
• The test of an account listed twice in one batch moves from initialize to addRecipients.
• Coverage of XanV2Vesting and its deploy script stays at 100%, and lint and Slither are clean.

Docs:

• docs/03-XanV2Vesting.md and DEPLOYMENT.md describe adding the recipients after the deployment. In DEPLOYMENT.md, the address check moves after the deployment, before the new step "Add the recipients".

script/xan-v2-vesting-recipients.json stays. A follow-up PR adds a script that reads it and proposes the addRecipients call to the council multisig.

Check:

• The order of the steps in DEPLOYMENT.md section 5: the council multisig adds the recipients before it computes and sends the first top-up, because the top-up scripts read the principals from the proxy.
• The signature of initialize changes. The contract is not deployed yet, so no deployment is affected.