fix(runtime): pass a reset type, not a reason, to reset_system

[sunnyrishy]

Summary

__stack_chk_fail, the handler that runs when the stack protector detects
memory corruption, asks the system to halt rather than to reset. It does
this by passing a constant from the wrong enum. The comment directly above the
call says "Trigger immediate system reset", so the code does the opposite of
its stated intent.

Type of Change

• fix — Bug fix
• build — Build system or dependency changes

Changes

• core/runtime_services.c — pass EOS_RESET_COLD instead of
  EOS_RESET_SOFTWARE from __stack_chk_fail, and document why the two enums
  must not be mixed.
• CMakeLists.txt — promote -Wenum-conversion to -Werror=enum-conversion
  on GCC/Clang so this class of mistake cannot come back.

The defect

There are two reset enums, and they overlap numerically:

Enum	Meaning	Value 2
eos_reset_reason_t (include/eos_types.h)	why a reset already happened	EOS_RESET_SOFTWARE
eos_reset_type_t (include/eos_runtime_svc.h)	which reset to perform	EOS_RESET_HALT

eos_rtsvc_reset_system() takes an eos_reset_type_t. The call passed
EOS_RESET_SOFTWARE, a reason. Because both are 2, it silently becomes a
request to halt.

For a secure bootloader this inverts the security response: detecting a
stack-smashing attempt should reset into a controlled boot path, but halting
leaves the device wedged until someone power-cycles it — a detected attack
becomes a denial of service.

GCC had been reporting this the whole time; it was one warning among the ~9 the
native build emits, so it went unread:

core/runtime_services.c:138:28: warning: implicit conversion from
'enum <anonymous>' to 'eos_reset_type_t' [-Wenum-conversion]

Approach

The one-line correction is passing the right constant. The more useful half is
making the mistake impossible to repeat: -Werror=enum-conversion turns any
future cross-enum pass into a hard build failure.

I checked before enabling it — enum-conversion had exactly one occurrence
in the entire tree, the one fixed here, so the flag is clean everywhere else and
does not force unrelated churn.

The flag is scoped to native GCC/Clang builds (NOT CMAKE_CROSSCOMPILING),
deliberately. CI cross-compiles for ARM Cortex-M4, and I have no ARM toolchain
locally, so I am not willing to promote warnings to errors in board code I have
not actually compiled — that is how a guard turns into a broken pipeline. Native
builds cover core/ and hal/, the platform-agnostic code where this class of
mistake arises and where this defect lived, so the guard still catches exactly
what it needs to. MSVC has no equivalent flag, so the MSVC job is unaffected.

If maintainers with the cross toolchains in hand confirm the board tree is
clean, widening this to cross builds is a one-word change.

Testing

• Unit tests pass (ctest --test-dir build --output-on-failure)
• Manual testing performed

Native build, GCC 15.2 (MinGW-w64), -DEBLDR_BUILD_TESTS=ON:

• Before: 1 enum-conversion warning. After: 0.
• ctest: 13/14 pass, unchanged by this PR. The single failure is
  test_recovery, which fails to link (undefined reference to eos_boot_log_get_head / eos_boot_log_append). That is pre-existing and
  unrelated — it is already addressed by fix: link eboot_stage1 into test_recovery #35.

Verifying the guard actually guards — reintroducing the old constant now breaks
the build rather than warning:

core/runtime_services.c:143:28: error: implicit conversion from
'enum <anonymous>' to 'eos_reset_type_t' [-Werror=enum-conversion]
cc1.exe: some warnings being treated as errors

Considerations and limitations

• The bug is latent today, not live. eos_rtsvc_reset_system() currently
  does (void)type; and ignores its argument on every platform, so nothing
  misbehaves at runtime right now. I want to be precise about that rather than
  overstate the impact. It goes live the moment any platform honors the
  parameter — which the enum's own COLD/WARM/HALT values clearly
  anticipate — and it would then be a silent, security-relevant wrong action in
  the hardest place to debug one.
• I did not implement type handling. Making eos_rtsvc_reset_system()
  actually distinguish cold/warm/halt is per-platform work that cannot be
  validated on a host build, so it belongs in its own change. Happy to open a
  follow-up issue if that is wanted.
• Two enums sharing the EOS_RESET_* prefix for different concepts remains a
  latent trap. A rename (e.g. EOS_RESET_REASON_*) would remove the ambiguity
  at the source, but it is a public-header API break, so I kept this PR to the
  defect plus the compiler guard rather than bundling it.

Pre-Submission Checklist

• Code compiles without warnings — this removes the only enum-conversion
  warning in the tree. Other pre-existing warnings (unused variables in
  ed25519_verify.c, unused parameters in boot_menu.c) are untouched and
  out of scope here.
• All existing tests pass — 13/14, unchanged by this PR. test_recovery
  fails to link on master and is already addressed by fix: link eboot_stage1 into test_recovery #35.
• New tests added for new functionality — the -Werror guard is the
  regression test; reintroducing the defect now fails the build.
• Documentation updated if API changed — n/a, no API change
• Commit message follows <type>(<scope>): <description>
• Branch is rebased on latest master (0 commits behind)

Related Issues

None. test_recovery's link failure seen during validation is unrelated and
already covered by #35.