Expected HTTP status code for an action on a disabled resource

Seems like that is the Internet's consensus, and I see nothing better here. See here for another similar question

409

This code is used in situations where the user might be able to resolve the conflict and resubmit the request. Source

This is then followed up

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request

That seems more like the entity shifted underneath the client while the client constructed a call, perhaps the assumption is the client asks for the allowed actions, before making the call(s). If you implemented that, I would say 409 is perfectly valid for your API since you provide the ability for clients to make only valid requests, unless someone else changes the entity.

Clearly you should be consistent, and document the response codes and their usage.

According to RFC 4918 (https://www.rfc-editor.org/rfc/rfc4918#section-11.2), you could use code 422 (Unprocessable Entity) to handle situations like it.

422 Unprocessable Entity

The 422 (Unprocessable Entity) status code means the server
understands the content type of the request entity (hence a
415(Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct (thus a 400 (Bad Request)
status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML
request body contains well-formed (i.e., syntactically correct), but
semantically erroneous, XML instructions.