How Chrome Measures LCP
At the start of page load, the browser begins a stopwatch to track time it takes to see the largest content on the page.
Chrome paints content in a series of stages. Different stages occur as the browser loads content on the page, or when changes are made to the DOM (whether its css, js, etc) and it's got to be re-painted.
In each stage, which I suppose you could think of like a "stroke" (of a paint brush) the browser looks for the largest content that is visible above the fold. After each stage the largest content found is reported.
If/when the browser finds content that is larger than what it has saved, it makes note of how long it took to see it from when the timer started.
Once the user starts interacting with the page, the last reported largest content is the Largest Contentful Paint time.
For some odd (and ironic) reason, in the last stage, the browser is reporting that element below is both above the fold and larger than the last largest thing reported.
<p class="text-white-50 pt2">
<small>
Example Text
</small>
</p>
The only logical reason I can think of as to why that would occur is because it was above the fold. I typically see anomalies like this when there's a lot of render blocking and layout shifting going on.
To fix your problem you first have to understand it.
Start isolating variables
Ignore LCP for awhile and make sure you've optimized everything else that you possibly can.
Make sure you've eliminate all render blocking and layout shifting and then test this again.
When all of that is done you should be pretty fast. But if this phenomenon persists, add the following directly after your opening <body> tag:
<img width="99999" height="99999" style="pointer-events: none; position: absolute; top: 0; left: 0; width: 99vw; height: 99vh; max-width: 99vw; max-height: 99vh;" src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c3ZnIHdpZHRoPSI5OTk5OXB4IiBoZWlnaHQ9Ijk5OTk5cHgiIHZpZXdCb3g9IjAgMCA5OTk5OSA5OTk5OSIgdmVyc2lvbj0iMS4xIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIj48ZyBzdHJva2U9Im5vbmUiIGZpbGw9Im5vbmUiIGZpbGwtb3BhY2l0eT0iMCI+PHJlY3QgeD0iMCIgeT0iMCIgd2lkdGg9Ijk5OTk5IiBoZWlnaHQ9Ijk5OTk5Ij48L3JlY3Q+IDwvZz4gPC9zdmc+">
It will work, however this is not intended to be a long term solution.
This should be used as a hack to squash a relentless bug if after you optimize everything this phenomenon still persists. I am not advocating that you fool search engines into thinking you have good UX.
Here's some other answers I've written to questions about Core Web Vitals that you might find useful:
Question where site needed to fix DOM priority and provide resource hints
^ at the end of my answer you'll find links to:
CLS Question Where DOM Priority Was an Issue
CLS Question Where FCP Image Was an Issue
<p><small> text </small></p>text that is being reported as your LCP exist? Down far by footer? What happens if you drop it from the DOM?