Commands `buffer_ports` and `repair_design` insert delay and clock buffers instead of just data buffers (sky130)

Describe the bug

In short, my question is, should I expect buffer_ports/repair_design to pick normal data buffers (*_buf_*), or is it expected behavior for the commands to pick clock (*_clkbuf_*) and dedicated delay cells that are not designed (or desired) for this purpose? If this is expected behavior I can fix it with a cell exclusion list, otherwise this is a regression in OpenROAD.

The comparison is done between:

1. the old OpenROAD version used in OpenLane,
2. newer versions used in LibreLane (the current LibreLane dev branch is using a version of OpenROAD from about a week after the 26Q2 tag).

The buffer_ports picks clock delay buffers:

[INFO RSZ-0027] Inserted 34 sky130_fd_sc_hd__clkdlybuf4s25_1 input buffers.
[INFO RSZ-0028] Inserted 1 sky130_fd_sc_hd__clkdlybuf4s25_1 output buffers.

Similarly repair_design picks clock/data delay buffers and normal clock buffers to fix fanout/slew/maxcap issues. I can prevent this behavior by adding undesired cells to the set_dont_use list.

A more detailed breakdown of the issue with version details and "Buffer Report" can be found here:
https://github.com/librelane/librelane/issues/944

Expected Behavior

The expected behavior would be for the commands to only use different strength data buffers (*_buf_* or *_bufbuf_*) which would to my understanding be the optimal choice.

Environment

not right now

To Reproduce

For example run this command using the dev branch of LibreLane:

librelane test/designs/spm/config.json

Relevant log output

Screenshots

No response

Additional Context

No response