@x.getter is valid at runtime (albeit not common). We probably don't want to emit an "Only supported top decorators are ..." error for it.

I guess we don't have any tests for it 🤷

Hm. This definitely needs a test, but I think rejecting @prop.getter is a reasonable thing to do: it should override the existing getter, supporting it properly won't be trivial, so explicitly saying "we don't support redefined getters" is not that bad (given that such usage should be really rare, 0 primer hits)

By following this github search, I identified two common patterns with @prop.getter (excluding partial subclass overrides as they don't trigger this code and aren't supported anyway):

1. Mistake with getter instead of setter (followed by signature def (self, value))

2. Obscure way of defining properties:

    class A:
        @property
        def foo(self): pass
        
        @foo.getter
        def foo(self):
            ...  # Some logic here
        
        @foo.setter
        def foo(self, new_foo):
            ...

   Honestly this makes my eyes bleed. I don't know how popular this is as regex code search is limited to 5 pages, and the file count estimate is never close to reality, they don't actually regex-match whole github. I propose to accept the risk and wait - if we get a couple of tickets about this in the next release, we can whitelist getter as well.

As a secondary reference, pyright handles this in the most confusing manner possible, we don't want to replicate that behaviour. It silently accepts any @prop.getter even with incompatible return type and ignores it completely - see my ticket microsoft/pyright#10633

The relevant pyright ticket was closed wontfix, but I still think allowing getter and ignoring it isn't optimal:/

Would it make sense to warn about duplicate setters/deleters here?

Property support is fragile, I'm afraid to touch it too deeply:) This is definitely a good idea, but I'll defer that to a follow-up PR - let's keep such changes as minimal as possible.