It's an overscan issue. Basically, Eevee does a lot of his work using "what the camera sees". That's why for example you might see screenspace reflections fade out on the picture's edges. Bloom is affected by this as well.
In the viewport, "what the camera sees" correspond to your viewport, even when in camera perspective. But when rendering, it is restricted to your camera. Hence, the difference. It's usually not that big of a problem for most render, but since you're in a somewhat extreme case scenario where the bloom effect is used on a very large portion of the picture, it really makes a huge difference.
Now how to fix this is quite simple: you need to let the renderer see more around your sphere.
To do this, you can manually adjust the camera position when rendering to be a bit wider and then crop it afterwards to your needs, or you can use the overscan feature which basically does almost the same thing but without you needing to do the job:
By default, you can't go higher than 10% by dragging the button, but you can manually write down higher values. Try and see what works for you.
Your scene seems to be all properly set (same sampling, no Simplify, no hidden objects etc), so the "issue" seems to be with Blender, not with you overlooking some settings. In other words, you probably have to live with it for now.
Just to be sure there weren't any hidden settings or objects in your scene that were interfering, I was also able to reproduce the behaviour with a entirely new scene (although in my case the render seems dimmer).
It looks like the feature that originates the difference is Eevee's "Bloom". Without Bloom, the world color matches perfectly.
I'm not sure whether this is a bug or one of the unavoidable differences between "Render" and "Rendered Viewport" (like, for example, anything that has to do with the concept of screen space), and therefore if it should be reported to the developers or not.
I've also checked whether you're affected by a known bug of Blender 2.83 with viewport color management: https://developer.blender.org/T77909, but even with Blender 2.82 (unaffected by the bug) your scene seems to suffer a mismatch.