Fix: level CANN dlog before rtSetDevice so device logs honor log_level

[hw-native-sys-bot]

Summary

PR #723 (collapsed ChipWorker::init / set_device into a single
simpler_init) silently flipped the order of attach_current_thread
and the dlog_setlevel block inside simpler_init on both a2a3
and a5 onboard. CANN snapshots the device-side log session's
level at device-context open time (rtSetDevice inside
attach_current_thread), so a dlog_setlevel issued after that
is a no-op for the device side.

Net effect: when ASCEND_GLOBAL_LOG_LEVEL is not set in the
environment, the log_level the user passed to Worker(...) /
configure_logging(...) silently fails to reach the device-side
filter — ~/ascend/log/{debug,run}/device-N/*.log files are either
missing or pinned at CANN's default (logLevel=3 / ERROR).

Pre-#715/#723 the order was correct because init and set_device
were two separate C entries called in the right sequence; #723
merged them and the dlog ordering was silent collateral. Sim has
no CANN dlog and is unaffected.

The fix

Hoist the existing dlog_setlevel block above
attach_current_thread in both onboard simpler_inits. HostLogger
is already seeded by libsimpler_log.so's simpler_log_init()
(runs earlier in ChipWorker::init), so
HostLogger::get_instance().level() is already the user's choice at
this point — no new plumbing needed.

The comment on the hoisted block now explains the rtSetDevice
ordering constraint so this doesn't silently regress again.

Files

• src/a2a3/platform/onboard/host/pto_runtime_c_api.cpp — hoist
• src/a5/platform/onboard/host/pto_runtime_c_api.cpp — same hoist
• src/common/worker/pto_runtime_c_api.h — simpler_init doc
  comment: responsibilities reordered (dlog first), wording explains
  the constraint
• docs/logging.md, docs/dynamic-linking.md,
  docs/chip-level-arch.md — call-flow diagrams updated to match
  the new order (per .claude/rules/doc-consistency.md)

Sim variants (src/{a2a3,a5}/platform/sim/host/pto_runtime_c_api.cpp)
are untouched — they have no CANN dlog.

Hardware verification

Ascend910 / a2a3 onboard, device 2, tiny driver script
(Worker.init → close) with configure_logging("debug") and
ASCEND_GLOBAL_LOG_LEVEL unset:

	first line of ~/ascend/log/run/device-2/device-{pid}_*.log	~/ascend/log/debug/device-2/device-{pid}_*.log
Before (PID 845511)	logLevel=3, ccecpulogLevel=-1, aicpulogLevel=-1	not created
After (PID 856602)	logLevel=0, ccecpulogLevel=-1, aicpulogLevel=-1	76 KB of DEBUG entries

With ASCEND_GLOBAL_LOG_LEVEL=1 exported (PID 860263), device
shows logLevel=1 regardless of configure_logging("debug") —
the getenv guard correctly defers to the env var, so that path
is unchanged.

Existing onboard ST (tests/st/aicore_op_timeout, #762) still
passes in ~8 s after the rebuild.

Test plan

• Pre-commit hooks (clang-format, cpplint, markdownlint,
  check-headers) pass on all 6 files without SKIP=.
• Hardware before/after captures recorded above.
• ASCEND_GLOBAL_LOG_LEVEL-set path unchanged.
• Existing onboard a2a3 ST still passes (no regression).
• CI runs the full hardware pipeline.

Fixes the regression introduced by #723.

[gemini-code-assist]

Code Review

This pull request reorders the initialization sequence in simpler_init to ensure that dlog_setlevel is called before the device context is opened via rtSetDevice. This change is necessary because CANN snapshots the log level at context-open time, making subsequent level changes ineffective for the device-side session. Documentation across several files has been updated to reflect this new order. The review feedback suggests explicitly including the header in the platform-specific implementation files where std::getenv is utilized to ensure portability.