[RISC-V] Console only uses the deprecated legacy SBI interface, silent on firmwares without it #401

Description

On RISC-V, hvisor's console has exactly one path: the SBI legacy console (EID 0x01 putchar / 0x02 getchar).

• src/device/uart/mod.rs:35-38 — on riscv64, device::uart unconditionally resolves to the wrappers below. There is no UART driver and no alternative branch.
• src/arch/riscv64/sbi.rs:50-60 — those wrappers call sbi_rt::legacy::console_putchar / console_getchar.
• src/logging.rs — all hvisor log output goes through them.
• src/arch/riscv64/sbi.rs:100-112 — guest (VS-mode) legacy console calls are forwarded to the same path.

None of the six boards under platform/riscv64/ defines BOARD_UART_BASE, and there is no DBCN usage anywhere in the tree.

Impact

The legacy console extension is deprecated. Firmware that implements only the modern extensions (for example RustSBI) does not provide EID 0x01 / 0x02; the call returns SBI_ERR_NOT_SUPPORTED and the return value is discarded — so there is no error, no panic, and not even the startup banner. Any boot failure becomes undiagnosable.

This is currently blocking a QEMU boot test for hvisor under RustSBI (rustsbi/rustsbi#361). It also affects more than hvisor's own logging: guest SBI console output (for example a VS-mode Linux earlycon) is forwarded through the same path and is lost with it.

Proposed change

Move the hvisor → firmware call to DBCN (EID 0x4442434E), keeping a legacy fallback:

1. sbi_console_putchar uses sbi_rt::console_write_byte (already provided by the pinned sbi-rt 0.0.3, no dependency bump needed).
2. On first output, probe DBCN once via PROBE_EXTENSION (EID 0x10 / FID 0x3), cache the result, and fall back to legacy when it is unavailable.
3. Keep the guest-facing EID 0x01 / 0x02 matching unchanged (it is guest ABI); just route it through the same backend function.

The compatibility set grows from {legacy} to {legacy ∪ DBCN}: firmware that works today keeps the same behaviour, while firmware implementing only DBCN is newly supported.

One note: legacy itself cannot be probed the same way. OpenSBI registers it as the extid range 0x0..0x8, so probe(0x01) reports "available", whereas RustSBI reports "unavailable". The fallback is therefore "probe DBCN, otherwise default to legacy", without probing legacy.

Verification plan

• hvisor's banner appears under RustSBI Prototyper (cargo prototyper build -f hypervisor) on QEMU virt;
• guest legacy console output still appears;
• fallback path checked with an OpenSBI built with CONFIG_SBI_ECALL_DBCN=n, confirming hvisor still prints via legacy.

Questions for maintainers

• Preferred backend order: DBCN first with legacy fallback, or UART-first on boards that define a UART?
• Runtime probe, or a per-board Kconfig option?