Feature request: bus / vector wires — render one edge for a contiguous port slice

Description

Allow a set of edges connecting a contiguous port slice between two blocks to be rendered and
manipulated as a single bus edge:

• Collapsed by default when a drag connects a slice, or when N parallel edges between the same
  block pair are detected — drawn as one thicker line, labelled with the slice (e.g. species[0:10]
  or a user-supplied name like exhaust).
• Expandable on demand — click to fan out into the individual edges for inspection or to rewire
  one channel, then re-collapse.
• Purely a view concern. The underlying .pvm graph, the Connection objects, and the exported
  Python would be unchanged — a bus is a grouping annotation over existing edges, not a new
  connection type. That keeps pathview convert output identical and means no PathSim-side change
  is needed.

Two smaller things that would compose well with it, though they're separable:

• Drag from a port group (shift-drag, or drag from a block edge rather than a handle) to create the
  whole slice in one gesture, instead of ten drags.
• A bus label on the edge — this overlaps with #8 (Add labels/annotations to Edges), so the two may
  want to share an implementation.

Problem

PathSim handles multi-variable signals well via port slices — Connection(a[0:10], b[0:10]) is
concise in Python and works exactly as you'd want. In PathView the same connection is 10 separate
edges, because each port is an individual handle.

For anything with a chemical or multi-species signal this scales badly. We're building a fusion
fuel-cycle and balance-of-plant block library on PathSim, where every stream carries a molar-flow vector over a species basis, typically 10 species (H2, HD, HT, D2, DT, T2, He3, He4, N2, NT3), and users can extend the basis at runtime.
A ~25-block fuel cycle therefore draws roughly 250 edges for what a person reading the diagram
thinks of as ~25 pipes.

The Python model is fine. It's the diagram that stops being readable, which is a shame because the
diagram is the reason to use PathView at all.

This isn't fusion-specific — it applies to any chemistry, thermofluid, or power-system model where a
"signal" is naturally a vector.

Alternatives Considered

No response

Additional Context

No response

Start by tracing the existing edge rendering, port-handle drag behavior, and multi-edge handling in the PathView frontend. Define how contiguous slices, labels, collapse/expand interaction, and group dragging should fit the current view model without changing the .pvm graph, Connection objects, or exported Python. Done means bus edges remain view-only, can be expanded and re-collapsed, and preserve existing graph output.