[Bug]: postgrest fails to start because of missing DLLs required

[develop7]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues/PRs to ensure it has not already been reported or fixed.
• I have verified that I am using the latest version of Scoop and corresponding bucket.

Package Name

postgrest

Expected/Current Behaviour

Expected:

a console window would blink

Instead:

postgrest.exe doesn't start, citing the absence of LIBPQ.DLL in a message box, see screenshot below

Steps to Reproduce

0. Install Windows (e.g. Win10 LTSC 2021 evaluation), install chocolatey
1. `scoop install postgrest`, then open `scoop/shims` in Explorer
2. double-click postgrest.exe

Possible Solution

Ship {libcrypto-3-x64,libiconv-2,libintl-9,libssl-3-x64,libwinpthread-1,libpq}.dll (as per https://github.com/PostgREST/postgrest/pull/3469/files#diff-944291df2c9c06359d37cc8833d182d705c9e8c3108e7cfe132d61a06e9133ddR202) along with the postgrest.exe

Scoop and Buckets Version

PS C:\Users\vboxuser> scoop --version
Current Scoop version:
v0.4.2 - Released at 2024-05-14

Scoop Config

PS C:\Users\vboxuser> scoop config

last_update
-----------
2024-06-27T15:40:59.6824199+02:00

PowerShell Version

PS C:\Users\vboxuser> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.19041.1237
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.1237
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Additional Softwares

No response

UPD: sister issue for chocolatey — majkinetor/au-packages#245

In before "why PostgREST does not ship them along with the executable" — PostgREST/postgrest#3469. TL;DR: it's not out job; we don't know where to get them canonically; EnterpriseDB (first obvious source of them) license doesn't allow to redistribute them.

[develop7]

I've figured a more or less canonical source of DLLs in question and made a PR that hopefully addresses the issue: #6212