The recommended approach is saveEntityRecord against the wp_navigation post type — this is what core itself does in packages/block-library/src/navigation/edit/use-create-navigation-menu.js:

import { useDispatch } from '@wordpress/data';
import { store as coreStore } from '@wordpress/core-data';

function useCreateMegaMenuNav() {
    const { saveEntityRecord } = useDispatch( coreStore );

    return async () => {
        const newPost = await saveEntityRecord( 'postType', 'wp_navigation', {
            title:   __( 'Mega Menu' ),
            content: '<!-- wp:navigation-link {"label":"Home","url":"/"} /-->',
            status:  'publish',
        } );
        return newPost?.id;
    };
}

saveEntityRecord returns the persisted record (including id) on success, so you can chain it into a setAttributes( { ref: newPost.id } ) on your core/navigation instance to link it.

A clean wiring inside your jumbo/mega-menu block's edit:

const { saveEntityRecord } = useDispatch( coreStore );
const { updateBlockAttributes } = useDispatch( blockEditorStore );

useEffect( () => {
    // navRef tracks the inner core/navigation block's clientId
    if ( ! navRef || alreadyLinked ) return;

    ( async () => {
        const newNav = await saveEntityRecord( 'postType', 'wp_navigation', {
            title:  `Mega Menu — ${ clientId }`,
            status: 'publish',
            content: '',
        } );
        if ( newNav?.id ) {
            updateBlockAttributes( navRef, { ref: newNav.id } );
        }
    } )();
}, [ navRef ] );

Two things worth flagging:

• Run-once guard: an effect keyed on the inner navigation block's clientId fires when the InnerBlocks template instantiates it. Without an "already linked" check (e.g. tracked in your block's own attributes), you'd create a new wp_navigation post on every mount. Persist a linkedNavId in your block's attributes once the post exists, and short-circuit if it's set.

• Edit-mode vs. view-mode: in template parts / patterns and during pattern preview, your block's edit can mount in contexts where you do NOT want to materialise a new CPT (template thumbnail rendering, pattern picker, etc.). Gate the saveEntityRecord call on useBlockEditingMode() returning 'default', or on useSelect( select => select( editorStore ).getCurrentPostType() ) matching real post types you expect this to live in.

If you need the menu's content to be authored from the parent block's InnerBlocks, the inverse pattern (read the navigation CPT's blocks, dispatch them as InnerBlocks of your container at mount) is also valid — but it requires keeping the source-of-truth in wp_navigation and treating your container's InnerBlocks as a derived view. Both work; choice depends on whether your menu structure is authored inside the mega-menu container or shared across the site.