A directly blocked <img> still pays the full inline-image encode

Affected: rrweb-snapshot, serializeElementNode. Anchors below are from the copy bundled by rrweb 2.0.0-alpha.17 (dist/rrweb.js), where I read them directly; the same ordering is present in rrweb-snapshot 2.0.1.

needBlock is computed early (dist/rrweb.js:808), but the img / inlineImages branch runs at :897, before the point where needBlock replaces the element's attributes with just class, rr_width and rr_height (:952). So for an <img> that is itself blocked, the canvas draw and toDataURL still execute in full and the resulting rr_dataURL is then discarded.

Blocking an ancestor avoids the work, because descent stops there (recordChild = recordChild && !serializedNode.needBlock, :1095).

To be precise about the cost: a directly blocked image does not cost more than an unblocked one — it costs the same, and the result is thrown away. The surprising part is that marking an element as blocked suppresses the output without skipping the work, so it cannot be used to avoid the expense.

Suggested fix. Check needBlock before entering the img/inlineImages branch.