`2bad98e` ("feat: support border-width shorthand and per-side *-width longhands") has a real bug: `applyBorderWidthShorthand` bails out entirely if **any** side in a multi-value shorthand fails to parse as a positive width:

```js
function parseBorderWidth(value) {
  const widthPx = keywordWidths[trimmed] ?? parseFloat(trimmed);
  return Number.isFinite(widthPx) && widthPx > 0 ? { widthPx } : undefined;  // 0 -> undefined
}

function applyBorderWidthShorthand(value, result) {
  const parts = value.split(/\s+/).map(parseBorderWidth);
  if (parts.some((part) => part === undefined)) return;  // bails if ANY part is 0
  ...
}
```

For a perfectly common declaration like `border-width: 1px 0px` (horizontal borders only — 1px top/bottom, 0 left/right), the `0px` component parses to `undefined` because of the `widthPx > 0` check. That makes `parts.some(undefined)` true, so the function returns early **without setting any of the four sides** — not just the zero ones. The result: the border is silently dropped entirely, including the legitimate 1px sides.

I hit this exact regression when I initially adopted their approach — it broke our `domDocxBorderPatch.test.ts` test for `border-width:1px 0px;border-style:solid;border-color:...`. Our patch avoids it by keeping `parseBorderWidth` defined even for `widthPx === 0` (`>= 0` instead of `> 0`), and instead special-cases zero-width at the final render step (`toSide`) to emit an explicit `NONE` border. That's why I skipped `2bad98e` when porting the other two commits (`127570a`, `d0ed6ae`) from that fork.