feat(shared): add owner-bound resource references

[testikun]

Problem

Direct Subagent, Workflow, and Background Terminal artifacts currently expose unrelated paths and ids with different completeness and lifetime semantics. Cross-capability consumers cannot tell what value a file is complete relative to, who owns it, whether its generation is stale, or whether receiving the path grants any authority.

Closes #157.

Value

Result details can now carry one compact, versioned reference shape while each producer keeps storage, cleanup, canonical state, and authorization. Consumers get explicit owner/generation/revision/lifetime/completeness metadata without adding a global router or another read tool.

Approach

• add a shared owner-bound file-reference contract for Subagent, Workflow, and Background owners;
• publish only after a regular, non-symlink file exists beneath the producer root;
• distinguish complete owner values from partial projections and name the source-coverage boundary;
• classify invalid, owner mismatch, stale generation, owner lost, unauthorized, traversal, symlink, missing, and stale-revision failures;
• attach references to Direct Subagent CAS results, terminal Workflow result/transcript/agent-result artifacts, and settled Background Terminal spill streams;
• preserve owner-specific lifetimes and Pi-native read/Trust enforcement; add no URI router, global store, index, or model-facing recovery tool.

Validation

• bun run check — passed.
• focused shared reference and three-producer adapter tests — 59 passed, 0 failed.
• full Node 22 suite — 1,248 passed, 1 skipped, 0 failed.
• Vitest suite — 30 passed, 0 failed.

Impact

• User-visible behavior: artifact-bearing result details gain optional resource metadata; no UI changes.
• Model-visible context/tools: no new tools or resident prompt; existing Pi-readable paths remain.
• Runtime/lifecycle: publication is post-write and owner-scoped; references do not extend producer retention.
• Persisted config/data: no config change; terminal Workflow manifests may persist bounded resource-ref metadata.
• Compatibility/risk: additive fields only; legacy details/artifacts remain readable. Revision uses owner generation plus path/file metadata and is rechecked by the owner resolver; it is not advertised as a content hash.