Fix pio.write_images ignoring layout width and height

[breken-ai]

Link to issue

Follow-up to #5325, which fixed this for to_image/write_image but not for write_images. I couldn't find an existing issue for the write_images case, and I'm happy to open one if you'd prefer.

Description of change

pio.write_images ignores layout.width/layout.height, and the template's size too, so every figure is exported at the default 700x500. write_image and to_image have used the argument, then layout, then template, then defaults order since #5325. write_images still passed d["width"] or defaults.default_width straight to Kaleido. Batch-exporting a figure built for 1200x300 therefore gives a squashed 700x500 image, while exporting the same figure alone gives the right size. This PR moves the width/height resolution from to_image into a small _resolve_width_height helper and uses it for every figure in write_images.

Demo

import plotly.graph_objects as go
import plotly.io as pio

fig = go.Figure(go.Scatter(x=[1, 2], y=[1, 2]), layout=dict(width=800, height=600))
pio.write_image(fig, "single.svg")      # 800x600
pio.write_images([fig], ["batch.svg"])  # before: 700x500, after: 800x600

Testing strategy

I added test_write_images_width_height_priority next to test_width_height_priority in tests/test_optional/test_kaleido/test_kaleido.py. It exports three figures through real Kaleido and checks the SVG sizes: layout size only, a width argument overriding the layout, and no size at all. On main it fails with (700, 500) != (800, 600), and with this change it passes. The rest of test_kaleido.py passes too, apart from test_image_renderer, which needs IPython and also fails on main in my environment. ruff format --check is clean.

Additional information (optional)

to_image behaves exactly as before, since the helper holds the same expression. I found this bug and wrote the fix with the help of an AI coding assistant, and I checked the change and the test output myself.

Guidelines

• I have reviewed the pull request guidelines and the Code of Conduct and confirm that this PR follows them.
• I have added an entry to the changelog if needed (not required for documentation PRs).