fix(viz): draw hyperedges in network coords to fix HiDPI offset

[nhkimmm]

fix(viz): draw hyperedges in network coords to fix HiDPI offset

Fixes #334.

Problem

drawHyperedges in _hyperedge_script manually re-applies the network view transform on top of a ctx that vis-network has already transformed for the afterDrawing hook, and uses canvas.width / 2 as a center anchor. canvas.width is the physical pixel buffer (cssWidth × devicePixelRatio), not the CSS width, so on DPR = 2 (Retina) the anchor lands cssWidth / 2 to the right and cssHeight / 2 down — and the doubled transform compounds the error. Net effect: hyperedge convex hulls render disconnected from their nodes in the lower-right area of the viewport. See #334 for the full analysis.

Fix

Take the ctx from the afterDrawing callback argument (already in network coordinate space) and draw node positions directly. Remove the toCanvas helper and its scale / offset / canvas locals. The network.on('afterDrawing', drawHyperedges) registration is unchanged — vis-network calls the callback with (ctx), so the new drawHyperedges(ctx) signature binds automatically.

After this change, hyperedge rendering uses the same coordinate space as vis-network's own node/edge rendering, so it is correct on any devicePixelRatio by construction.

No other changes: colors, alpha, expansion factor (1.15), font, label position, and the hook name are all left as-is, so this reviews as a pure coordinate-math fix.

Verification

• macOS 15 Retina (DPR = 2), Chrome + Safari: hyperedge polygons now render tightly around their referenced nodes on a corpus with 3 hyperedges spanning 3–5 nodes each. Confirmed visually before and after.
• DPR = 1 not directly tested, but after the fix hyperedges use exactly the same coordinate path as nodes/edges — so if nodes render correctly at a given DPR, hyperedges will too.

Out of scope

Self-intersecting hyperedge polygons for 3+ nodes drawn in extraction order (not convex hull). Separate follow-up.