Settle attachment scrolling before opening the Save menu

[dnlbui]

What Changed

The multiple-attachment download scenario now uses AttachmentMenu.open() to scroll the target into view and wait for stable position/layout across rendered frames before opening Save. The wait is bounded at five seconds.

The named download waiter starts only after Save is visible and is awaited together with the Save click. Existing filename, size, and byte-for-byte checks remain intact.

Fixed Flow

Scroll attachment into view → wait for scrolling/layout to settle → open and verify Save → start the waiter and click Save together → verify downloaded bytes.

Why

Playwright's implicit scrolling could deliver a scroll event just after the attachment click, closing the newly opened menu as the client intends. The old waiter also remained active when menu opening failed, producing a secondary page-closed error during cleanup.

No client behavior or visibility timeout changes are included. Shared failure evidence before recipient cleanup follows in the next stacked issue, #78.

Validation

Against https://liberdus.com/dev/, from playwright-tests/:

CI=true ./node_modules/.bin/playwright test tests/attachments.e2e.test.js --project=chromium --grep 'should send and download multiple attachments' --workers=1 --retries=0 --repeat-each=3 --trace=on --reporter=line --output=/tmp/liberdus-issue79-validation

• Three runs passed in 4.2 minutes, verifying all five attachment downloads and byte comparisons each time.
• A focused temporary browser harness passed in Chromium, Firefox, and WebKit: offscreen attachment opens its menu, intentional scrolling dismisses it, and Save downloads the expected filename.
• The harness also verified bounded failure during continuous layout changes in Chromium.
• Syntax/diff checks and an independent make-code-skimmable pass passed; changes are limited to the helper and affected scenario.

Stacked on #82, base test/update-account-option-selectors.

Closes #79