fix: preserve POS payment amounts during draft creation

[my-dev-jour]

Summary

• preserve cashier-entered POS payment rows across set_missing_values() in update_invoice()
• restore the original payment rows before totals/account assignment continue
• resync paid_amount and base_paid_amount after restoring payments
• add a focused regression test for the payment snapshot/restore helpers

Root Cause

ERPNext rebuilds POS payment rows during set_missing_values() from POS Profile defaults. POSNext was calling that flow during draft creation without restoring the cashier-entered payment rows, so a paid sale could be saved/submitted with zeroed or replaced payments and end up unpaid.

Validation

• validated on ERPNext 16.11.0 staging with a real POS flow
• confirmed submitted invoice preserved payment rows and showed outstanding_amount = 0
• local verification was limited to py_compile in this workspace

Notes

• this supersedes the earlier GL-focused hypothesis from PR fix: rebase POS sales invoice GL entries on ERPNext 16 #209; the staging test showed the immediate root cause was payment-row loss during draft creation

[my-dev-jour]

CI server passed. The remaining failing checks appear to be repo-level workflow/lint issues rather than regressions from this patch: the dependency audit cannot resolve ERPNext in CI, and the linter runs pre-commit with --all-files, which surfaces existing repo-wide formatting and Ruff issues outside this change.