<picture> handling sets img src to the smallest srcset candidate in HTML output #406

When an <img> sits inside a <picture>, the picture rule in src/elements/images.ts overwrites the image's src with extractFirstUrlFromSrcset() of the best <source>. Since srcsets are usually listed smallest-first, parse().content ends up pointing at the thumbnail. This happens even when the original <img src> was already the full-size image, and even though the rule's comment says it is meant to get the highest resolution.

c5adda3 (from #177) made the Markdown conversion prefer the widest srcset candidate. The HTML output still has this problem, so anyone who consumes content as HTML gets the smallest rendition.

Repro (defuddle 0.19.4, linkedom):

const u = (w) => `https://substackcdn.com/image/fetch/$s_!abc!,w_${w},c_limit,f_webp,q_auto:good/https%3A%2F%2Fexample.com%2Fimage.png`;
const html = `<html><body><article><h1>Post</h1><p>${'Text. '.repeat(100)}</p>
<figure><picture>
  <source type="image/webp" srcset="${u(424)} 424w, ${u(848)} 848w, ${u(1272)} 1272w, ${u(1456)} 1456w" sizes="100vw">
  <img src="${u(1456)}" width="1456" height="900" alt="Chart">
</picture></figure>
<p>${'Text. '.repeat(100)}</p></article></body></html>`;
const doc = new DOMParser().parseFromString(html, 'text/html');
new Defuddle(doc, { url: 'https://example.substack.com/p/post' }).parse().content;
// <img src="…w_424…"> — the original src was w_1456

This affects every Substack post, and any site that serves <picture> with ascending srcset.

Expected: the picture rule picks the widest candidate (the same selection the Markdown path now uses), or keeps the <img>'s own src when it's valid.

Related: #315 deals with the same rule, where it overwrites a valid src when the <source> srcset has no descriptors.