runtime-bringup

Implement the runtime contract first: 28 C ABI functions declared in csrc/include/flagos.h plus 10 DeviceMemoryInterface allocator virtuals, split across device.cc, memory.cc, and stream.cc. Then wire the USE_<VENDOR> macro at three CMake sites and pass the operator-free smoke test before registering any operators.

Pick based on the SDK shape: accelerator/cuda for libcudart shims, accelerator/musa for renamed CUDA-style APIs like Kunlun XPU's xpu_malloc, accelerator/ascend or gcu for different execution models, and accelerator/bpu when the chip has no stream concept.

StreamQuery and EventQuery must return ErrorNotReady for still-running work, not a generic error. The caching allocator's block-reuse path treats ErrorNotReady as not safe to reuse yet and anything else as a hard failure, so collapsing it causes deadlocks or memory corruption.

Default to false for a new chip and use the built-in block pool. Return true only if the platform ships a mature caching allocator that does not claim the PrivateUse1 allocator slot torch_fl registers, as the MUSA backend demonstrates.

The most common cause is forgetting to add USE_<VENDOR> to the negative CUDA-include guard in caching_device_allocator.cc. Both cuda_memory.h and your header then get included, producing duplicate definitions or wrong-backend selection that points nowhere near the real cause.

Use CUDA-compatible boxing when the vendor ships a torch wheel containing libtorch_cuda.so whose nm output shows at::add and at::mm symbols, since it is roughly an order of magnitude less work. Otherwise implement a native operator backend, deciding from SDK evidence rather than marketing claims.