The controller you are arguing with

There are three objects, not one

A Deployment does not create pods. It creates a ReplicaSet and sets its replica count. A second controller turns that count into pods. Each pod carries an owner reference back to the ReplicaSet, and the ReplicaSet carries one back to the Deployment.

That chain is why deleting a Deployment removes the pods without the Deployment controller knowing pods exist — and it is why a change you make to the middle object does not survive. The Deployment controller will look at its ReplicaSet, see a number it did not write, and put its own back.

Scaling a ReplicaSet directly is the classic version of this. It works, briefly. The reconcile that undoes it is not a bug and there is no event announcing it.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
spec:
  replicas: 3
  selector:
    matchLabels:
      app: checkout
  template:
    metadata:
      labels:
        app: checkout
    spec:
      containers:
      - name: api
        image: checkout:v1

Two writers, one object

Every object carries a resourceVersion. A write that names the version it read is refused if anything has written since. That is the mechanism that turns a lost update into an error you can see.

It is also how a fight becomes visible. Two controllers that both believe they own an object will both write to it, and the conflict count is the evidence. A cluster that is churning with nothing obviously wrong is usually two loops disagreeing about what should exist.