webtau: add runtime info / capability introspection API

[devallibus]

Summary

webtau now supports multiple runtime paths, but consumers still mostly branch on isTauri() or ad hoc provider knowledge. A small runtime introspection surface would make feature detection clearer and give downstream apps a more stable way to adapt behavior.

Why this matters

• It reduces runtime-specific branching in app code.
• It gives experimental runtimes a cleaner path without expanding the public API surface too aggressively.
• It makes diagnostics, docs, and tests easier to reason about because the active runtime and supported capabilities become explicit.

Suggested scope

• Add a small runtime info API, for example getRuntimeInfo().
• Expose stable fields such as runtime id and capability flags rather than leaking implementation details.
• Keep it compatible with the current provider model and Tauri/WASM defaults.

Example shape

const runtime = getRuntimeInfo();
// { id: "wasm" | "tauri" | "electrobun" | string, capabilities: { fs: true, events: true, ... } }

Acceptance criteria

• Consumers can query the active runtime without relying on isTauri() alone.
• Consumers can make capability-based decisions through a documented API.
• Tests cover the default WASM path, Tauri auto-registration, and provider-based runtimes.
• Docs include guidance on capability-based branching.