Extent log message about conflicted shards

## Description

In my installation, in CouchDB logs messages I can see messages like
```
1 conflicted shard in cluster
```
I have tried to delete old databases and in the server logs can see
```
[critical] 2024-03-26T17:28:24.081510Z couchdb@db-2.example.com <0.16743.70> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:28:29.187245Z couchdb@db-2.example.com <0.18085.70> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:28:34.311446Z couchdb@db-2.example.com <0.21253.69> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:28:39.541320Z couchdb@db-2.example.com <0.31584.67> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:28:44.649152Z couchdb@db-2.example.com <0.20660.67> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:28:49.717562Z couchdb@db-2.example.com <0.23910.70> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:28:54.921189Z couchdb@db-2.example.com <0.9403.70> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:00.033066Z couchdb@db-2.example.com <0.19084.68> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:05.174271Z couchdb@db-2.example.com <0.25777.70> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:10.262848Z couchdb@db-2.example.com <0.30249.69> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:15.402787Z couchdb@db-2.example.com <0.27844.70> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:20.721704Z couchdb@db-2.example.com <0.20999.70> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:25.680320Z couchdb@db-2.example.com <0.100.70> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:30.777084Z couchdb@db-2.example.com <0.243.71> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:35.905120Z couchdb@db-2.example.com <0.23983.70> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:41.078100Z couchdb@db-2.example.com <0.4260.71> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:46.252992Z couchdb@db-2.example.com <0.5119.71> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:51.305345Z couchdb@db-2.example.com <0.6351.71> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:29:56.444482Z couchdb@db-2.example.com <0.6549.71> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:30:01.605705Z couchdb@db-2.example.com <0.5639.61> -------- 1 conflicted shard in cluster
[critical] 2024-03-26T17:30:06.766324Z couchdb@db-2.example.com <0.9687.69> -------- 1 conflicted shard in cluster
```
These log messages do not provide information about:
1) database with conflicts;
2) shard file;
3) conflicted revision id.

Could you extent logs message?
## Steps to Reproduce

I do not know

## Expected Behaviour

Log messages should allow identifying conflicted database, shard, and revision id.

## Your Environment

[TIP]: # ( Include as many relevant details about your environment as possible. )
[TIP]: # ( You can paste the output of curl http://YOUR-COUCHDB:5984/ here. )

* CouchDB version used:
```json
{
"couchdb": "Welcome",
"version": "3.3.3",
"git_sha": "40afbcfc7",
"uuid": "385419103339-esrp",
"features": [
"access-ready",
"partitioned",
"pluggable-storage-engines",
"reshard",
"scheduler"
],
"vendor": {
"name": "The Apache Software Foundation"
}
}
```
* Browser name and version:
Not used

* Operating system and version:
```
NAME="CentOS Stream"
VERSION="8"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Stream 8"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_SUPPORT_PRODUCT_VERSION="CentOS Stream"
```

## Additional Context

[TIP]: # ( Add any other context about the problem here. )

Start by searching the Erlang codebase for the exact log text, "conflicted shard in cluster," and trace which database, shard, and revision information is available at that point. The change is done when the recurring log identifies all three requested values and the affected logging behavior is verified with suitable coverage.

Written by the indexing model from the issue text.