feat(docker): stricter request validation and bind mount rules

[oleksandr-nc]

HaRP passed the Docker create payload to the Engine mostly as it arrived, so a typo in a mount mode silently produced a read-write mount and bad values only failed later with an opaque Docker error. The agent now validates the payload up front and answers 400 with the reason before anything is created. New HP_EXAPP_BIND_MOUNTS_DISABLED, HP_EXAPP_BIND_MOUNTS_ALLOWED, HP_EXAPP_BIND_MOUNTS_DENIED and HP_EXAPP_BIND_MOUNTS_ENFORCE_ALL settings restrict which host paths ExApps may bind mount, with a default list of system paths (see the README). docker-engine-port is limited to HP_DOCKER_ENGINE_PORTS, credentials and app secrets are masked in the log, and the unit tests run inside the built image in a new workflow.

Visible changes for administrators:

• Every /docker/exapp/* and /k8s/exapp/* endpoint answers 400 with a field: message reason for: names, instance ids and role suffixes that do not start with a letter or digit, contain anything outside [A-Za-z0-9_.-] or are longer than 63 characters; on create, a network_mode that is empty or contains :, blanks or control characters, an unknown restart policy, negative or non-integer resource limits, mount paths that are relative or contain :, .. or control characters, and a mount mode other than ro/rw (such stored mounts used to become read-write).
• Mounts of the default deny list are refused. Its broad entries (/dev, /run, /var/run, /root) and its read-write entries (/etc, /usr, /bin, /sbin, /lib, /lib64, /var/spool) only log a warning in this release, because AppAPI re-sends stored mounts on every ExApp update after removing the old container; HP_EXAPP_BIND_MOUNTS_ENFORCE_ALL=true refuses them now. See "Upgrading" in the README.
• docker-engine-port must be in HP_DOCKER_ENGINE_PORTS (default 24000-24099, the Docker Engine ports of the FRP server); other values get 400, or 403 on the Docker API passthrough. This includes remote engines on 23000-23999.
• harp-shared-key no longer reaches ExApps, and neither it nor AppAPI's Authorization header reaches the Docker Engine.
• FRP logins without a token are refused with 400 and count toward the IP ban (they used to fail with 500); IPv6 FRP clients get a ban bucket per address. A wrong shared key on a request from AppAPI behind a trusted proxy now counts against the client from X-Forwarded-For, not against the proxy.
• A malformed value of one of the new settings stops HaRP at startup, with the reason as the last log line.