system/nxpkg: network sync, install hardening, and CLI completion

[aviralgarg05]

Note: Please adhere to Contributing Guidelines.

Summary

This PR completes the package lifecycle work introduced in #3474. The initial
implementation supported local metadata and basic install/list operations;
this change adds the network and lifecycle operations needed to use nxpkg as
a practical on-device package manager.

The main changes are:

• add repository synchronization and package downloads over HTTP, with SHA-256
  verification of downloaded artifacts;
• implement the sync, update, remove, rollback, and available CLI
  paths, and allow install to use either local or network sources;
• recover cleanly from interrupted downloads and installations;
• validate manifest paths and bound allocations and input sizes before using
  repository-provided data;
• harden metadata storage against truncated files and serialize updates to the
  installed-package database so concurrent installs cannot overwrite one
  another;
• support an optional package icon used by graphical frontends;
• handle custom boards through CONFIG_ARCH_BOARD_CUSTOM_NAME when
  CONFIG_ARCH_BOARD is not defined;
• route package diagnostics through syslog, which also works when no console
  is attached; and
• document the repository layout and local server setup in
  system/nxpkg/README.txt.

This PR depends on the package lifecycle foundation merged in #3474. #3643 is
a graphical frontend that depends on the APIs added here; #3644 is independent.

Impact

When CONFIG_SYSTEM_NXPKG is enabled, users gain a complete package lifecycle:
repository sync, local or remote installation, update, removal, rollback,
listing, and discovery of available packages.

Network operations additionally require CONFIG_NETUTILS_WEBCLIENT; the
existing CONFIG_NETUTILS_CJSON dependency remains. Local-only installations
do not require network access.

The install path now performs network I/O when given a remote source and uses a
global lock while updating installed-package state. Repository metadata is
treated as untrusted input, including path components and declared sizes.

Existing applications are unaffected unless CONFIG_SYSTEM_NXPKG is enabled.
The on-disk development format has gained fields for icon and transaction
state; no migration is provided because the format introduced by #3474 has not
appeared in a release.

Testing

Build host:

• macOS 26.5, arm64
• xtensa-esp-elf-gcc 14.2.0 (esp-14.2.0_20241119)

Target:

• Xtensa / ESP32-S3
• esp32s3-touch-lcd-7:nsh on a Waveshare ESP32-S3-Touch-LCD-7
  (custom, not-yet-upstream board configuration)

The complete image was built and the package lifecycle was exercised repeatedly
on the physical board. The verified flows included repository sync from a local
HTTP server, remote install, update, removal, rollback, listing, and application
launch. Interrupted install state was recreated and successfully reclaimed.
Two different packages were also installed concurrently; both remained present
in the installed-package database after completion.

The custom-board compatibility fix was checked against the generated
include/nuttx/config.h, where CONFIG_ARCH_BOARD is absent and
CONFIG_ARCH_BOARD_CUSTOM_NAME is defined:

$ xtensa-esp32s3-elf-gcc -c -fsyntax-only \
    -I <nuttx>/include -isystem <nuttx>/include -D__NuttX__ -D__KERNEL__ \
    -I <apps>/include -I system/nxpkg \
    system/nxpkg/pkg_compat.c system/nxpkg/pkg_log.c
# completed successfully