I would say it's a controller, because it is integrated with the Kubernetes system and reacts to changes to objects.

An operator generally creates Kubernetes objects as part of implementing a complex workflow that is normally taken care of by a human "operator". An example of this is the Cassandra operator, where you save a single object describing a Cassandra cluster at a fairly high level and the operator takes care of creating the pods and volumes and services and configuring the databases (and tearing it all down when you don't want it anymore).

Controller is usually reserved as the implementation that satisfies an API, regardless of what it does. Operators hide operational complexity via judicious use of APIs - if using it in the broadest sense the ingress API + a particular controller implementation (nginx which is a deployed object vs an ALB which might just be programmed) is an “operator”.

A Postgres operator could manage Postgres instances in pods, or it could program AWS RDS. Having a deployable entity isn’t really required. The thing reading the API and updating those objects is definitely a controller.

Although an ingress operator could be even higher level and ensure one or more ingress controllers were actually deployed (if you had an IngressController resource that made it easy to deploy them)

I wouldn't call this an operator since it isn't operating other applications.

It's a controller which is configured by Kubernetes Custom Resources that extends Kubernetes as you say.