Support patchable Ash.Resource actions DSL section

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

### AI Policy

- [x] I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

### Is your feature request related to a problem? Please describe.

Currently, the actions section in Ash.Resource is not patchable?: true, which makes it difficult for extensions to add custom action-like DSL entries that reuse almost the same DSL as read.

For example, I wanted to define a DSL like this:
```elixir
actions do
hiding_read :list do
hidden_attribute :hidden_at

visible :list_visible
hidden :list_hidden

prepare build(sort: [ord: :asc])
end
end
```
hiding_read would accept almost the same DSL as read, with a few additional DSL entries for configuring the hidden attribute and which visible/hidden read action variants should be generated. A transformer would then add normal Ash.Resource.Actions.Read actions.

### Describe the solution you'd like

I would like the `actions` section to be patchable, so extensions can add custom action-like entities there.

In particular, it would be useful if a patched entity with a custom target could live inside `actions`, define its own nested DSL entries, reuse most of the existing read DSL, and then be transformed into normal `Ash.Resource.Actions.Read / Create / Update / Destroy` entities by a transformer.

This would be useful for cases where a read action wants to reuse the normal read DSL but add a small behavior on top, such as caching or visibility/soft-delete variants.

### Describe alternatives you've considered

The current workaround is to use a sidecar section:
```elixir
actions do
read :list do
prepare build(sort: [ord: :asc])
end
end

hiding_reads do
read :list do
hidden_attribute :hidden_at

visible :list_visible
hidden :list_hidden
end
end
```

### Additional context

_No response_

Start by tracing the Ash.Resource actions section and the existing patchable-section and transformer mechanisms described in the issue, then compare the requirements for reusing the read DSL. Done means an extension can add a custom nested action-like entity under actions and transform it into normal read, create, update, or destroy entities.

Written by the indexing model from the issue text.