Can't specify map_hash_max_size in http_top.conf

Checklist

• Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
  • Yes
• Are you sure you're not using someone else's docker image?
  • Yes
• Have you searched for similar issues (both open and closed)?
  • Yes

Describe the bug
The documentation promises that tossing stuff into http_top.conf will include it at the top of the http directive block. Unfortunately, this is actually not the case as in the nginx.conf it is included online 73 (the http section begins at line 25) after some boilerplate. This is a problem, because I'm trying to set map_hash_max_size but it fails because on line 56 it includes a map directive, which implicits it to 64 (since it wasn't defined yet) and causes nginx to [emerg] on the config for having a duplicate setting.

Nginx Proxy Manager Version
Version 2.12.3 (c5a319c) 2025-03-12 00:21:07 UTC

To Reproduce
Steps to reproduce the behavior:

1. Map a file to /data/nginx/custom/http_top.conf with the contents:

    map_hash_bucket_size 256;

3. Attempt to configure anything (or probably just start the container. I did the config updates while it was running but it will likely result in the same issue)
4. Observe that no config changes can be saved as it is permanently invalid due to the "duplicate" directive.

Expected behavior
I expected the docs to match reality. If the include was actually at the top of the http directive, none of this would be a problem.

Ideally, the boilerplate conf lines should be auto-generated and remove any directives that are specified in http_top.conf so things like the desired map hash bucket size or no-delay options can be configured at-will (side note, why is it setting defaults explicitly. tcp_nodelay is already "on" by default, why is it being set in the first place?).

Screenshots

Operating System
Technically I'm using TrueNAS Scale's docker orchestration, but I think this will apply to literally any setup due to it being a configuration issue.

Additional context

I think technically a workaround for this exact issue (besides moving the include to where the docs say it is) would be to lower the "default upstream scheme" below the include.

Compare the advanced configuration documentation with the generated nginx.conf, focusing on the http block around lines 25 and 73 and the map directive around line 56. Reproduce the failure with a mounted http_top.conf containing map_hash_bucket_size 256; done means the documented include ordering works without a duplicate-directive error, or the documentation accurately reflects the supported ordering.