activeIndex desynchronization after appendSlide with loop: true

Context

Swiper's loop mode creates duplicate slides (clones) at both ends to enable infinite scrolling. These clones are not reflected in the swiper.slides array, causing a mismatch between the internal clone indices and the visible slide order when slides are mutated at runtime.

Problem

Calling appendSlide, prependSlide, or removeSlide after initialization with loop: true desynchronizes the internal loop clone indices from the visible slide order. The documented loopDestroy and loopCreate methods rebuild clones but reset the active index to 0 unless explicitly preserved. Swiper 11 introduced loopFix and loopDestroy/loopCreate APIs, yet the documentation does not specify a guaranteed sequence for preserving the active slide position during runtime slide mutations with loop enabled. Event handlers like slideChangeTransitionEnd may fire with incorrect activeIndex values immediately after dynamic slide operations until loop reconstruction completes.

Constraints

• Must preserve the user's current visual slide position across mutations
• Cannot disable loop mode or switch to virtual slides
• Autoplay timers and ongoing transitions must not be interrupted

What is the minimal sequence of API calls that guarantees realIndex and activeIndex remain consistent after appendSlide or removeSlide with loop: true? Does loopFix provide a stable alternative to full destroy/create cycles? How should custom pagination logic account for the slidesLength versus swiper.slides.length discrepancy during the reconstruction window?