Why not just use one of the established definitions?
E.g. ISO/IEC/IEEE 24765:2017 defines systems engineering (SE) as "interdisciplinary approach governing the total technical and managerial effort required to transform a set of stakeholder needs, expectations, and constraints into a solution, and to support that solution throughout its life".
Or - if you prefer - the definition provided by INCOSE (https://www.incose.org/systems-engineering): "Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods."
This is just an "elevator speech" definition, not the whole body of knowledge. Systems Engineering is an engineering major; it takes several years to get a degree, and usually several years before that to get an engineering degree in a specialty area. If you are interested in the required qualifications, there is a lot of material for that as well; e.g., the EIA-731 "Systems Engineering Capability Model" standard. Or see e.g. https://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineer... which has at least a summary of nearly every relevant aspect of the field.
If the CSS is part of a system or system element, and the system is considered large enough to involve systems engineering, then yes, there is both a development and logistics support system which are analyzed, designed and implemented; fixing the CSS will either be under the development system or the logistics support system; but keep in mind that SE does not replace, but integrate the different disciplines; so it won't be a systems engineer fixing the CSS, but there was a systems engineer who planned and help implement the corresponding life cycle system where the maintenance happens.
I'm not familiar enough with CSS to understand if you're filing this under bugs with the language / spec or if you mean bugs in developed webpages.
In either case, fixing bugs would fall under the support aspect of what they listed. The full design, development, deploy stages would also fall under that and may be used in various amounts of formality when dealing with bugs.
There is an engineering design process [1] that anyone can learn about and take some useful ideas from. Obviously adapt what's relevant to your needs and discard the overly process or paperwork heavy details that may not be suitable.
There are SDLCs [2] and other software specific IEEE standards that have been developed [3]. If you've been in tech long enough, you've probably figured these out on your own, or some approximation to them, and you may have even come up with your own name for aspects of it. I've seen "metaprogramming" used a number of times on HN to describe aspects of the planning, analysis, and design stages of engineering design.
There definitely are things to be learned by looking at other fields, and I don't think software can claim absolutely zero overlap with other fields. It's not 100% and there are unique constraints, but it's not zero and throw the baby out with the bathwater so to speak.
