Inspecting the channel coefficients returned by comm.RayleighChannel, appears to add static delay in front of the line-of-sight path, is this a bug?

I am using comm.RayleighChannel to generate a Rayleigh faded wireless channel. As an example of what I think is a bug that I'm observing, I use the following settings to create a channel object, apply it to my signal and get the channel gains (aka channel coefficients):

fs = 100e6; % sampling rate Hz
pathDelays = [0 278]*1e-9; % sec
avgPathGains = [0 -0.9]; % dB
fD = 0; % doppler shift Hz

rayleighchan = comm.RayleighChannel('SampleRate',fs, ...
    'PathDelays',pathDelays, ...
    'AveragePathGains',avgPathGains, ...
    'MaximumDopplerShift',fD);

x = randi([0 1],1000,1);
y = rayleighchan(x);

rayleighchaninfo = info(rayleighchan);
channel_coeffs = rayleighchaninfo.ChannelFilterCoefficients;

plot(sum(channel_coeffs))

Since the pathDelays and avgPathGains assign a 0 to the first path, I expect to see one of the two paths to be at delay 0 and the second path to be at delay 278 ns, as shown below. The impulse at 278 ns delay occurs between samples which creates the spreading you see in the figure.

Now if I change the pathDelay and avgPathGains to this

pathDelays = [0 4]*1e-9; % sec
avgPathGains = [0 -2.7]; % dB

There appears to be only one strong path at the center of the impulse response. The problem is that it looks like this is adding 7 samples of delay before the peak to my signal, which I cannot tolerate as this is for a localization simulation, where signal delay translates to position in space. I understand that the 4 ns offset between the main line-of-sight (LOS) path and the non-LOS path is below the sample period (10 ns), so it appears merged into one single peak, but that does not explain the delay that is being added before this peak.

Is there something I can do to ensure that the impulse response of the channel does not add static delay before the first path?