chore(spec): propose anonymised scene + ring-runtime .tri specs upstream in t27

[gHashTag]

chore(spec): propose anonymised scene + ring-runtime .tri specs upstream in t27

Info-drop, async-only.

Context

Two .tri specifications derived from an anonymised subset of a downstream
multibot / worker system are landing in gHashTag/t27 under:

specs/scenes/scene_schema.tri (ring-105-005) -- generic scene FSM
specs/runtime/ring_runtime.tri (ring-105-006) -- generic ring worker (rust STUB target)

Both specs are anonymised: no PII, no wallet addresses, no bot tokens, no tariff codes, no user IDs. Only structural schema (state machine, message envelope, backoff policy).

The intent is a schema-first SSOT that any ring-based worker system can point at, including trios. No code changes are planned in gHashTag/trios from this issue.

Three optional questions

1. Is specs/runtime/ the right home for a generic ring-worker schema, or should it live under specs/workers/?
2. Should the scene schema carry a versioned envelope (schema_version: u8), or lean on spec_hash for versioning?
3. Is there an existing trios discussion on a shared worker schema, to avoid duplication?

References

• specs at gHashTag/t27 (ring-105-005, ring-105-006)

No ask.