feat(skills): add robodojo G05 skill

[qinhan-lyu]

Problem

Upstream dev still has no unified robodojo Skill and no g05 profile, and the validated G05 flow only exists on the internal integration line. Two boundaries have to hold while upstreaming it:

• the Skill must not become a second home for benchmark/policy code - the RoboDojo benchmark node and the G05 policy node are Forge Nodes owned by framework/forge_runtime;
• PAOS must not carry a private runtime patch for this Skill.

The multi-file Node bundles this needs are the runtime capability proposed in #112, which is still open and not merged.

What / Fix

Add one robodojo Skill with a single formal g05 profile, in three commits that each stand on their own:

1. feat(skills): add the RoboDojo G05 skill - manifest, SKILL.md, Dora dataflow and the Gateway / bench-endpoint / benchmark profile configuration.
2. feat(robodojo): add install and inventory helpers - the per-run presign install helper, the unsigned schema-v3 index template and the inventory checker.
3. docs(robodojo): document delivery and node ownership - the Skill README and the delivery record.

Ownership boundary:

• The Skill ships description, manifest, profile, dataflow, install scripts and docs only. There is no nodes/ tree and no profiles/g05/bin/ launcher; every dataflow node runs ${FORGE_RUNTIME_BIN}/<entrypoint> from the installed Node bundles.
• Node sources live in framework/forge_runtime. The lock pins three node digests and declares the four required binaries (gateway, bench_endpoint, robodojo_benchmark, robodojo_policy):
  • forge_runtime / forge-runtime-0.1.0 - gateway, built from forge_gateway v1.0.2; digest cee927eb587f3f958c1803086e59692f6f7ae373477b3cfd15118d01d76c408e
  • robodojo_endpoint / robodojo-endpoint-0.1.0 - bench endpoint; digest b9a66fb07b04ee1f76bb8221f68f96b35d1f1ce136d3d6cf967cb7a34da8e159
  • robodojo_benchmark / robodojo-benchmark-0.1.0 - RoboDojo benchmark and G05 policy as one digest bundle with two entrypoints, because they share _core, config.py and adapters and run in the same Python environment; digest e48cf4e838ba73512ac1eb0c144ea17ea177bb56ad41e524c8332f9a38c19ff2
• gateway and bench_endpoint stay on the Node 0.1.0 objects that are already published; robodojo_benchmark is the new object key this PR introduces.
• The install helper presigns every bucket_key on each run, downloads each object once to confirm expected_sha256, writes the generated schema-v3 index to a private temp dir, prepares the isolated instance (config.json + py/sitecustomize.py), and resolves paos / tosutil via --paos / --tosutil, then PAOS_BIN / TOSUTIL, then PATH, with setup guidance when missing.
• The profiles/ tree that remains in framework/forge_runtime is a development example; the formal Skill configuration lives here. The node build excludes it (skip_dirs contains profiles), so it never reaches a node archive.

Verification

Executed for this revision, without GPU, Isaac Sim, Dora or an Agent:

• Node bundles built from framework/forge_runtime; a Windows and a Linux build of the same tree now produce identical node_digest values (the builder sorts the payload inventory by POSIX path). Archive sha256 is host-dependent, so the lock pins node_digest.
• Skill packed from this branch with the official scripts/package_skill.py: archive sha256 1dd48cbeb536e853891ebb4b3ba816e4993b86407fa073dd679061dfceda6e0d (28825 bytes).
• Fresh isolated instance, confirmed empty of Skill / Node / lock / cache beforehand, installed through install_robodojo.py with the template's real object keys and its expected_sha256 values. It hash-matched all four archives - the two already-published Node objects (forge_runtime c524ae7038775e48f2b0a6036e621913b35b327ad2c710f8a8e0c5cad9e7613b, robodojo_endpoint 80b7076b04b8abf21712f6f3b11bd9523fde91d5e49bbe3ed202bf17f238e46c) plus this candidate's Skill (1dd48cbeb536e853891ebb4b3ba816e4993b86407fa073dd679061dfceda6e0d) and benchmark node (b07935a55610a9e80e29120a62997727fd54d0ba5f9e2e2bd60965436ecb686f) - and ended with Installed Skill robodojo 0.1.0. TOS presigning was replaced by a loopback HTTPS endpoint for this local run, because the two new objects are unpublished candidates.
• paos skill list reports robodojo 0.1.0 / g05 / not started; paos forge-node verify robodojo {forge_runtime,robodojo_endpoint,robodojo_benchmark} all report "verified against Skill lock".
• The profile environment materialises bin/{gateway,bench_endpoint,robodojo_benchmark,robodojo_policy} as relative symlinks into <runtime>/nodes/<node_id>/versions/<artifact_id>/bin/..., and the rendered launch/profiles/g05/dataflow.yaml resolves all four node paths inside that environment, never into the Skill tree and never through FORGE_PKGS_ROOT / BENCH_ENDPOINT_SRC.
• scripts/check_bundle_inventory.py --check reports all 11 Skill files matching the template inventory, categories included.
• python -m compileall -q PhyAgentOS, pytest -q (21 tests), ruff check PhyAgentOS tests and git diff --check passed on an earlier revision of this branch.

Reused historical evidence, not rerun here: the G05 end-to-end run, the PAOS Agent natural-language run, and the same-host fresh-instance install of the pre-split archive. final_acceptance remains pending; a presign run against real TOS for the two new objects and the GPU / Isaac Sim / Agent acceptance still have to happen before publishing.

Dependency: this PR requires #112. #112 is still open, is no longer a draft, targets dev, and its single commit is a6e4412b96d549401563afc73051a4e7b6115c1f; it currently conflicts with dev (mergeable_state: dirty), so it needs a rebase before it can land. On current dev, load_manifest() rejects the digest node lock, so this PR stays a draft until #112 is merged. profiles.<name>.startup_timeout_s is already supported by dev.