ABC9 is replacing missing ports with ports connected to 0, breaking Nexus carry chains

[gatecat]

Version

Yosys 0.61+56 (git sha1 1256091-dirty, g++ 15.2.1 -fPIC -O3)

On which OS did this happen?

Linux

Reproduction Steps

The approach used for carry chain synthesis for nexus always uses first carry feed in cell that does not have a CIN port on it. This is because in practice, two carry chains might be placed next to each other so the CIN of the first (coming from hard routing) needs to be a "don't care":

yosys/techlibs/lattice/arith_map_nexus.v

Lines 67 to 76 in 33e4b1d

	// Carry feed-in
	CCU2 #(
	.INIT0("0xFFFF"),
	.INIT1("0x00AA"),
	.INJECT("NO")
	) ccu2c_i (
	.A0(1'b1), .B0(1'b1), .C0(1'b1), .D0(1'b1),
	.A1(CI), .B1(1'b1), .C1(1'b1), .D1(1'b1),
	.COUT(FCO[0])
	);

(nextpnr strictly enforces this).

When running an adder design like this through synth_nexus -abc9, this is replaced with a CIN connected to a constant zero, which cannot be placed with how nextpnr handles this currently. This definitely used to be left disconnected at some point in the past...

module top(input [4:0] a, b, output [4:0] y);
assign y = a + b;
endmodule

 cell \VLO \y_OB_O_I_CCU2_S0_A1_VLO_Z
    connect \Z \y_OB_O_I_CCU2_S0_A1
  end

  attribute \module_not_derived 1
  attribute \src "add.v:2.12-2.17|/usr/local/bin/../share/yosys/nexus/arith_map.v:72.4-76.3"
  cell \CCU2 \y_OB_O_I_CCU2_S0_2_CIN_CCU2_COUT
    parameter \INIT0 "0xFFFF"
    parameter \INIT1 "0x00AA"
    parameter \INJECT "NO"
    connect \A0 \y_OB_O_I_CCU2_S0_D0
    connect \A1 \y_OB_O_I_CCU2_S0_A1
    connect \B0 \y_OB_O_I_CCU2_S0_D0
    connect \B1 \y_OB_O_I_CCU2_S0_D0
    connect \C0 \y_OB_O_I_CCU2_S0_D0
    connect \C1 \y_OB_O_I_CCU2_S0_D0
    connect \CIN \y_OB_O_I_CCU2_S0_A1
    connect \COUT \y_OB_O_I_CCU2_S0_2_CIN
    connect \D0 \y_OB_O_I_CCU2_S0_D0
    connect \D1 \y_OB_O_I_CCU2_S0_D0
    connect \S0 \y_OB_O_I_CCU2_S0_2_CIN_CCU2_COUT_S0
    connect \S1 \y_OB_O_I_CCU2_S0_2_CIN_CCU2_COUT_S1
  end

Expected Behavior

Either the CIN port remains missing/disconnected, or if this isn't easily possible to fix, then I'll need to rewrite the nexus techmaps and possibly some of the nextpnr support too...

Actual Behavior

See above

[gatecat]

Slightly confusingly, bisecting points to ec8d7b1