I don't think that this is a good idea.

On one hand, when maintainers move a column to indicate a "blessing",
the idea was to have no implications of this other than just the
blessing. This changes that simplicity into a "blessing and
potentially reset the staleness timeline if it's based on last
activity" -- complicated enough that nobody would remember it.

On the other hand, you're not ignoring bot column changes, which I first
thought was an ommision, but then I saw that you're relying on that in
the second commit. The main design decision that I like about this bot
(and is not due to me) is the fact that it's idempotent: it doesn't rely
on some external database or on adding meta-information as a "current
state" thing to be used later on. For example, we can run the bot at
any time and it won't lead to any changes (and this is a fact that is
was useful several times now: there's a periodic scan that runs it on
all PRs without worrying about leading to broken behavior, and to avoid
race conditions with multiple instances the a PR processing can be
canceled if a new trigger for the same PR arrived). It's something that
I did my best to not break -- and the one very minor exception is the
code that looks for a merge offer to determine if a merge request is
valid.

In any case, this breaks that in a more substantial way. It can lead to
bogus behavior (for example, if the column changes when a PR is inactive
for a while, the next iteration would see the change as activity and
change the column again). This might not be a problem now, but it can
lead to such problems with future changes, so I really don't want to do
it...

I'm with Eli, lets drop this one - thanks @jablko