[bug]: `entry` directive does not allow to set entry for some lines

[nschan]

Minimized .mmd repro

%%metro title: Example Pipeline
%%metro line: qc | QC | #2dd4bf
%%metro line: main | Main | #c792ea

graph LR
    subgraph input [Input]
        reads[Reads]
    end
    subgraph proc [Processing]
    %%metro entry: bottom | qc
        fastqc[FastQC]
        trim[Trim]
        align[Align]
        fastqc -->|qc,main| trim
        trim -->|main| align
    end
    subgraph results [Results]
        bam[BAM]
    end
    reads -->|qc,main| fastqc
    align -->|main| bam

Render command used

I am using the playground

Expected result

qc should enter section proc from the bottom, while main enters from the left.

Actual result

MixedEntryDirectionError: section 'proc' receives lines from more than one approach direction: bottom (qc), left (main). Routed lines have no arrowheads, so entries from different sides leave the flow direction ambiguous. Feed 'proc' from a single side (align the producers' grid columns so every line enters the same edge), or split it into separate sections.

Suspected subsystem

None

nf-metro version / commit

I am using the playground

[pinin4fjords]

Correction: this is a real bug, not working-as-intended. I closed it too fast on first pass, reopening.

The entry-side resolver (_build_entry_side_mapping in src/nf_metro/parser/resolve.py) works purely by line-id, with no memory of which station-to-station edge carried which lines together. In the repro, reads -->|qc,main| fastqc is a single connector, but internally it splits into two Edge objects, one per line. Since qc is named in %%metro entry: bottom | qc, it gets pinned to bottom; main isn't named, so it falls through to an independently-computed "natural" side (left, since input sits left of proc) - even though main and qc are riding the literal same connector and can't actually approach from different sides. That's what trips MixedEntryDirectionError.

This is narrower than "a section can only have one entry side" (that part's still true and correctly enforced elsewhere, e.g. mixed_entry_opposing.mmd / mixed_entry_perpendicular.mmd, which reject lines genuinely arriving via different edges). The bug is specifically that a directive pinning one line's side isn't propagated to sibling lines sharing the identical inter-section edge.

Fix is to make sibling line-ids on the same station-to-station edge inherit a directive-pinned side together, instead of resolving each line-id independently. Leaving open for that.

[pinin4fjords]

Fixed. Two things were going on here:

1. The reported bug: when %%metro entry: bottom | qc names only one line of an inter-section edge that carries several lines (reads -->|qc,main| fastqc), the entry-side resolver now propagates that hint to the other lines riding the same connector. Before, main fell through to its own independently-computed "natural" side and spuriously conflicted with the hint, even though it can't physically arrive from a different side than qc since they cross the section boundary together.

2. A second bug found along the way: building the regression fixture for (1) also exposed an unrelated routing defect: the engine had a dedicated routing rule for entries forced to the TOP of a section, but no equivalent for BOTTOM, so a BOTTOM-forced entry's route ran straight along the section's own boundary line instead of dropping in from below. Fixed separately in Missing BOTTOM-entry L-shape routing rule: same-row producer crosses target's boundary #1634 (merged first, since it's independent of the parser fix).

Both are merged now and the original repro renders cleanly.