Loop VFX (thruster flare, weld/grind particles, block lights) stop rendering after world reload; per

Summary:

Continuous/looping visual effects — thruster glow, welder/grinder particle beams, block lights — stop rendering after exiting to the main menu and reloading a save. The underlying block function is unaffected (thrusters still produce thrust, welders still weld); only the visual layer is lost. Reloading the save again does not restore it. A full game relaunch does.

Steps to Reproduce:

1. Start a survival world, build/use blocks with continuous VFX (thrusters, weld/grind tools, lights).
2. Play normally for a period, or exit to main menu and reload the save.
3. Observe: some or all continuous VFX no longer render, while the underlying block function continues working normally.
4. Reload again — issue persists.
5. Fully quit and relaunch the game, reload the same save — VFX render correctly again.

Expected behavior: VFX should render consistently regardless of save-reload, matching the block's actual functional state.

Notes for triage (from inspecting VRage.Render's public assembly docs — offered as a lead, not a confirmed root cause):

There appear to be two distinct mechanisms that could both produce this symptom, worth separating rather than treating as one bug:

1. Flares (Keen.VRage.Render.Data.FlareDefinitionObjectBuilder) drive visibility via a per-frame OcclusionToIntensityCurve sampled against the depth buffer (occlusion 0.3 → full intensity, 0.5 → zero). If the GPU occlusion query handle isn't correctly rebound after a scene reload, a stale/invalid query could plausibly report full occlusion by default, silently zeroing every flare's intensity without touching the definition data at all.
2. Particle effects (Keen.VRage.Render.Contracts.ParticleEffectEntity) are managed through an explicit handle (Id/IsValid) with lifecycle calls including InitializeEffect, StopEmitting/ResumeEmitting, and EnableDeferredDispose ("from this point, the effect has an implicit lifetime"). If a block's simulation-side code caches this handle across a scene reload without re-checking IsValid and re-calling InitializeEffect, it would keep calling StopEmitting/ResumeEmitting against a now-invalid reference — no error, no crash, just silence. This would also explain why only a full relaunch fixes it: that's the only path guaranteeing a fresh handle re-init.

The codebase also has a dedicated LoopedParticleEffectAttribute validator distinguishing looped vs. non-looped playback, consistent with looped effects specifically being the ones with a lifecycle-handle problem rather than one-shot effects (which init-and-forget and wouldn't hit a stale-handle issue the same way).

Related existing report: "[SE2] Thrusters don't have any visual effect anymore" (support.keenswh.com/spaceengineers2/pc/topic/50672) — same symptom, reload trigger, and workaround already independently confirmed there for thruster flare specifically; this report extends it to welder/grinder particles and block lights and adds a possible mechanism.