Django Admin actions configurable as buttons in the change view's object tools

## Code of Conduct

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

## Feature Description

In this feature proposal, we utilize Django 6.1's new `admin.action()` decorator's `location` parameter ([see docs](https://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/#admin-action-availability)) to add a choice for actions to be displayed as buttons on the change view, rather than the current drop down. Location options will thus be:

* `location=ActionLocation.CHANGE_LIST` (current)
* `location=ActionLocation.CHANGE_FORM` (current)
* `location=ActionLocation.OBJECT_TOOLS` (NEW!)

The new action buttons are located together with other object tools (the pill-shaped buttons).

Bulk actions continue to be the default, while single object actions are a configurable non-default behavior, meaning that the proposal is backwards compatible.

Thanks to people at the DjangoCon Europe 2026 sprints who took time to discuss this with me 💚

References:

* https://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/#admin-action-availability
* This is a concrete proposal to implementing [#12090 Show admin actions on the edit pages too](https://code.djangoproject.com/ticket/12090)
* An alternative discussion and PR emerged from the forum post [
Admin-Actions also in the object details view ](https://forum.djangoproject.com/t/admin-actions-also-in-the-object-details-view/22927) from 2023.

## Problem

Django Admin only supports actions on the list view, or as a dropdown+button on the change form (which takes up space on the screen and adds more clicks than necessary). But with the addition of https://github.com/django/django/pull/16012, we opted for new future action options to be added.

Evidence of the significance of the problem is seen from all the packages providing this functionality in various ways.

## Request or proposal

proposal

## Additional Details

* The current implementations for deleting single or multiple objects may be unified under this new definition. This could be explored subsequently.
* I suggest we leave this outside of the scope: If the action button is clicked on an unsaved/dirty change form, we might want to warn the user of losing unsaved changes.
* Button design hasn't been discussed. Should they appear in a separate row? Have a separate color? CSS class names?
* Confirmation is a universal issue for all actions: However, with a single-click button it becomes even more critical. By adding this feature, we should be aware that the avenue of a confirmation step might need to be explored subsequently.

## Implementation Suggestions

(the proposal was modified and has only 1 suggestion)

### Suggestion 1: CHANGE_FORM and OBJECT_TOOLS make no sense in combination

In this suggestion, we utilize a very simple logic: If you've added the action as a button, you probably don't want it in a drop-down at the same time.

Thus, we can distinguish between description and description_plural to create a meaningful short button label:

```python
@admin.action(
location=[ActionLocation.OBJECT_TOOLS, ActionLocation.CHANGE_LIST],
description="Publish",
description_plural="Mark selected stories as published",
)
def make_published(self, request, queryset):
queryset.update(status="p")
```

## Updates

* 2026-06-30: Updated to match the new `location` option introduced in 6.1