Automated release from CI pipeline

Changes:
release: ESP32-S3 firmware v0.6.5 — Tmr Svc stack + OTA init refactor (ruvnet#628)

Three fixes wrapped for the v0.6.5-esp32 release tag:

1. sdkconfig.defaults adds CONFIG_FREERTOS_TIMER_TASK_STACK_DEPTH=8192.
   The fix was already in sdkconfig.defaults.template (ADR-081, prevents
   "stack overflow in task Tmr Svc" bootloop when adaptive_controller emits
   feature_state from inside a Timer Svc callback). It was MISSING from the
   canonical sdkconfig.defaults file used by the build, so any fresh
   build picked up the 2 KiB FreeRTOS default and bootlooped on hardware.
   Verified on COM7: with the fix, no panics in 30 s of operation; without
   it, "ERROR A stack overflow in task Tmr Svc has been detected."
   followed by sustained bootloop.

2. ota_update.c extracts ota_load_psk_from_nvs() and calls it from
   both ota_update_init() and ota_update_init_ex(). main.c:230 uses
   the _ex variant, but only ota_update_init() was loading the PSK
   from NVS. Result: s_ota_psk stayed empty regardless of NVS contents,
   so the RuView#596 fail-closed posture rejected every request — but the
   diagnostic warning never printed at boot, leaving operators no signal
   about why their OTA uploads were 403'ing. Verified on COM7:
   W (3126) ota_update: NVS namespace 'security' not found —
   OTA upload endpoint will REJECT all requests until provisioned.
   Fail-closed per RuView#596.

3. version.txt: 0.6.4 → 0.6.5, paired with the v0.6.5-esp32 tag so the
   firmware-ci version-guard job (RuView#505 fix-marker) stays happy.

Both validations done end-to-end on hardware (COM7, ESP32-S3 8MB,
provisioned with --edge-tier 2 to also incidentally re-verify ruvnet#438 is not
reproducible on current main).

Docker Image:
ghcr.io/frontcover/RuView:f5e2b5474b3120797dd55db1c2b36c25e135dbc2