Fluent Forms 6.2.8: public CSS is enqueued on every front-end page of a block theme

File: app/Hooks/actions.php, the enqueue_block_assets callback (~line 1250).

add_action('enqueue_block_assets', function() {
    if (!is_admin() && !wp_is_block_theme()) {
        return;
    }
    ...
    wp_enqueue_style('fluent-forms-public', ...);
    wp_enqueue_style('fluentform-public-default', ...);
});

The early return only happens when we are NOT in the admin AND the theme is NOT
a block theme. But enqueue_block_assets also fires on the front end, and there
wp_is_block_theme() is true for every block theme, so the guard never bites:
both stylesheets are printed on every front-end page, whether or not the page
contains a form.

Impact on our site (WordPress 7.0.2, block theme, ~130 pages, exactly one page
with a form): 47 KB uncompressed / 8.8 KB gzipped and two extra render-blocking
requests on every page that has no form at all.

How to reproduce: on a block theme, open any front-end page without a form and
view the source. You will find the handles fluent-forms-public-css and
fluentform-public-default-css. The handle name is what identifies the source:
the legitimate render path in app/Modules/Component/Component.php registers the
same file under fluent-form-styles.

Suggested fix: the iframed block editor introduced in WP 6.3 still runs inside
an admin request, so the admin check alone should be enough:

if (!is_admin()) {
    return;
}

Workaround we use, in case it helps other block-theme users: dequeue both
handles on enqueue_block_assets at priority 999, but only when
wp_style_is('fluent-form-styles', 'enqueued') is false. That flag tells us a
form really did render. The condition matters: in a block theme the template
renders BEFORE wp_enqueue_scripts fires, so an unconditional dequeue removes
the style preset that the shortcode had already enqueued, and the form then
renders with browser-default input borders.