It's a real mystery for me... By the API calls and sampler parameters the game drives dgVoodoo, the flashlight should be repeated, as the case is.
There is no difference in the API driving with native D3D9 and it appears correctly with that...
Flashlight is a projected texture but the texture itself is sampled with address mode 'wrap', instead of 'clamp'. But I cannot understand how the (projected) texture coordinates can get clamped int0 [0..1] with 'wrap'.

It's not really conveyed by the game, but the flashlight is supposed to be emitted by the glaive weapon.
Throwing the glaive, while the flashlight is active, switches the projected transparent texture into a dynamic light that follows the glaive.

My guess is either that Digital Extreme originally concepted the flashlight to be 360° which would be more aligned with the weapon design and changed it last minute with some questionable code that somehow works, or the original flashlight was a constant dynamic light around the glaive and the switch from constant dynamic light to projected transparent texture is again just a last minute redesign with some questionable code that somehow works.

The port in itself seems to be held barely together with duct tape. Resolution changing, or alt-tabbing, pushes the system into pure chaos and widescreen resolutions clinch the aspect ratio.
It's fixable in the config files, but every half decent port shouldn't have those problems.
There is probably no easy fix. Your wrapper interprets the call correctly, but the game expects some shenanigans to work.

I don't really know the quality of the port. 😀 But anyway the question is why the rendering works natively.

Each texture has a texture sampler mode in the game asset, and the flashlight texture has a 'texture address wrap' sampler type. If I modify it to the expected 'clamp' in the memory from the debugger then flashlight is ok.
So, one of the possible (workaround) fixes would be finding that byte in the game data files and modify it there.