BUG: `getRecord()` causes memory exhaustion / 500 error for child elements rendered via `f:cObject` after update to 11.1.4

[eckonator]

After updating from 11.1.3 to 11.1.4, some frontend pages return HTTP 500 errors. In development
environments the error manifests as a PHP memory exhaustion crash. The issue was introduced by the
fix "Handle case where ContentObject data mismatches table name".

Root Cause

The change in AbstractFluxController::getRecord():

// Before (11.1.3):                                                                                                                                                                                                                                                                                                     
if (!empty($contentObject->data)) {
                                                                                                                                                                                                                                                                                                                          
// After (11.1.4):
if (!empty($contentObject->data) && $this->fluxTableName === $contentObject->getCurrentTable()) {     

When the new condition fails, the fallback relies on $tsfe->currentRecord ?: $contentObject->currentRecord
to retrieve the record from the database. This fallback fails in at least two scenarios:

Scenario 1 – Child elements rendered via f:cObject:

When a Flux grid element renders its child content elements using
<f:cObject typoscriptObjectPath="tt_content" data="{childRecord}"/>,
the ContentObjectRenderer passed to the child's controller has ->data populated correctly,
but getCurrentTable() does not return tt_content. The new condition therefore fails and the
fallback $tsfe->currentRecord points to the wrong (parent or page) record.

Scenario 2 – Pages with USER_INT content elements:

When any USER_INT element is present on a page, during the *_INT rendering pass
ContentObjectRenderer->data contains the page record and getCurrentTable() returns pages.
In 11.1.3 this was silently handled (returning page data was wrong but didn't crash);
in 11.1.4 the condition correctly rejects it, but the fallback may not have a valid
currentRecord set either.

Memory Exhaustion

In both scenarios the fallback can return a page record (e.g. when $tsfe->currentRecord
is pages:1) instead of the expected tt_content record. Fluid/Extbase then attempts to resolve
properties on this page record via Symfony's PropertyAccessor, triggering recursive relation
loading (FAL, categories, etc.) that exhausts all available memory:

PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted
in vendor/symfony/property-access/PropertyAccessor.php on line 306

On production servers this results in a generic HTTP 500 response.

Steps to Reproduce

1. Create a Flux grid content element that renders its children via f:cObject:

<f:section name="Main">                                                                                                                                                                                                                                                                                                   
    <flux:content.get area="content" render="false" />                                                                                                                                                                                                                                                                    
    <!-- then iterate and render each child: -->                                                                                                                                                                                                                                                                            
    <f:cObject typoscriptObjectPath="tt_content" data="{childRecord}"/>                                                                                                                                                                                                                                                     
</f:section>     

2. The child content elements are themselves Flux-based (contain flux:form in their template).
3. Open the frontend page → memory exhaustion / HTTP 500.

Alternatively:

1. Have any USER_INT content element on a page alongside a Flux content element.
2. Open the frontend page → memory exhaustion / HTTP 500.

Expected Behavior

getRecord() reliably returns the correct tt_content record in all rendering contexts,
including child elements rendered via f:cObject and *_INT rendering passes.

Actual Behavior

The fallback path resolves a pages record instead of the expected tt_content record,
causing Fluid/Extbase to enter recursive property resolution → PHP memory exhaustion → HTTP 500.

Environment

• TYPO3 version: 13.4.27
• Flux version: 11.1.4 (works correctly on 11.1.3)
• PHP version: 8.2
• Server: Nginx

Workaround

Pin Flux to 11.1.3 in composer.json:

"fluidtypo3/flux": "11.1.3"