Refactor: rename sche_cpu_num to aicpu_thread_num for honest semantics

[ChaoWao]

Summary

Pure rename, no behavior change. `Runtime::sche_cpu_num` was a legacy misnomer — the name implied "scheduler thread count" but the value was always the total AICPU thread count (orch + schedulers). The orch/sched split lived in `AicpuExecutor::init` as `sched_thread_num_ = thread_num_ - 1`, with the `-1` carving out the orchestrator thread. The runtime field name lied; the local `-1` did the bookkeeping the rename never did.

Renames

• `Runtime::sche_cpu_num` → `Runtime::aicpu_thread_num` (matches the user-facing `CallConfig::aicpu_thread_num` field — same name end-to-end)
• `AicpuExecutor::thread_num_` → `AicpuExecutor::aicpu_thread_num_`
• `SchedulerContext::thread_num_` → `SchedulerContext::aicpu_thread_num_` (and the `init()` parameter)
• `LOG_ERROR("Invalid thread_num:")` → `("Invalid aicpu_thread_num:")`
• Field doc-comment expanded to describe the orch/sched split (trb) or the no-split round-robin (hbg)

`sched_thread_num_` (the member holding `aicpu_thread_num_ - 1`) keeps its name — it accurately means "scheduler subset," and renaming it would only confuse the contrast with the new total field.

Drive-by

Two `platform_aicpu_affinity.h` files were missing the standard copyright header — surfaced by `check-headers` because the comment inside them was touched. Added the standard header to both (pre-existing omission, but no-skip rule applies).

Why

After PR #850, the user-facing field is `CallConfig::aicpu_thread_num` (clear: total) but it landed in `Runtime::sche_cpu_num` (confusing: implies scheduler-only). Reading `aicpu_executor.cpp:182-183` you have to figure out from context that `sche_cpu_num` means "total" — only the `-1` on the next line tells you. After this rename the same lines read:
```cpp
aicpu_thread_num_ = runtime->aicpu_thread_num;
sched_thread_num_ = aicpu_thread_num_ - 1; // -1 because the last thread is the orchestrator
```
Self-documenting.

Blast radius

28 files, 164/+122/− across `a5` + `a2a3` × `tensormap_and_ringbuffer` + `host_build_graph`. ChipWorker dlsym ABI is unchanged (the field rename is internal to the host/runtime contract; no exported symbol changed).

Test plan

• Local sim build (`pip install --no-build-isolation -e .`) clean
• `tests/ut/py/test_chip_worker.py` passes (14 tests)
• `tests/st/a5/.../spmd_basic` passes on sim (covers both Case1 with explicit block_dim and Case2_AutoBlockDim via the new path)
• All pre-commit hooks (clang-format, clang-tidy, cpplint, pyright, etc.) clean
• Onboard CI (st-onboard-a5 + st-onboard-a2a3) — needs CI run

[gemini-code-assist]

Code Review

This pull request renames the variable sche_cpu_num to aicpu_thread_num across the a2a3 and a5 platforms to clarify that it represents the total number of AICPU threads launched. The changes span multiple components, including the runtime, device runners, and executors. Additionally, copyright headers were added to the affinity header files. The review feedback identifies a logical issue in the initialization sequence within aicpu_executor.cpp for both platforms: sched_thread_num_ is calculated before a defensive fixup for a zero thread count, potentially resulting in an incorrect value of -1 when the total thread count is adjusted to 1.