Port `Service` from the `tinychain` mono-repo

Objective

Port the v1 Python Service authoring and invocation behavior to the current client, targeting backend Service execution in TinyChain-Inc/tc-server#43 and SyncChain in TinyChain-Inc/tc-chain#2.

Preserve ordinary Python declaration, member access, and method-call ergonomics while emitting the current canonical v2 definitions. This is a behavioral port, not a new authoring framework.

Pinned v1 reference

Revision: 17ef342e8f7026e4c4a60d2044de9aeb1b145b91.

• Service and Library authoring: Service.init, Service.json, member reflection, and self-bound method expansion.
• Chain and Sync wrappers: collection operation ergonomics, symbolic references, and Sync semantics.
• Backend member routing and member validation/construction.

Behavior to port

1. Let a user declare a Service with scalar attributes, methods using the existing decorators, and Chain-managed mutable collection members. Preserve inherited/reflected public members where supported by the current authoring model.
2. Require mutable persistent members to be managed by a supported Chain; reject bare mutable collections and invalid Chain subjects with actionable typed errors. Begin with Sync over supported collection schemas.
3. Bind declared methods to symbolic self/member references. Ordinary self.member operations must compile through the same canonical operation and lexical-scope machinery as other client code.
4. Preserve the wrapped collection's normal member/method ergonomics through a Sync-backed member. Reuse current symbolic/reference helpers instead of copying v1's dynamic subclass and private verb overrides mechanically.
5. Emit canonical v2 Service identity, definition, member schemas, and operations. Adapt v1's legacy URI slicing and nested constructor encoding to the current server contract. Reuse codecs/fixtures; do not introduce packages, compatibility envelopes, or a second serializer.
6. Keep external dependencies distinct from owned persistent members and preserve explicit dependency authority. Python inheritance/reflection must not grant ambient access.
7. Install and invoke through existing tc.install, backend, and host abstractions. Deferred authoring remains available; the same public Service definition works with local PyO3 and HTTP when backend support lands. No public transaction handles, raw URI assembly, replication controls, or Service-specific installer are required.

Implementation and dependencies

• Read client/py invariants and inspect current shared Library/Class/reflection helpers before adding code.
• Record a compact retained/adapted/unsupported v1 parity list beside the implementation documentation.
• TinyChain-Inc/tc-server#43 owns backend definition validation, method execution, and persistent-member integration.
• TinyChain-Inc/tc-chain#2 owns SyncChain durability/recovery.
• Deferred authoring, fixtures, and examples may proceed alongside those implementations. Live persistence acceptance requires both.
• TinyChain-Inc/tcv2#69 owns shared lifecycle operations; TinyChain-Inc/tcv2#70 owns integrated lifecycle evidence. Reuse those paths.
• JavaScript Service authoring remains in #86.

Acceptance criteria

• Define a Service containing a scalar, a Sync-backed collection, and read/write methods accessing self.member.
• Deferred method calls and member access produce canonical plans using existing lexical and operation rules.
• Definitions and member schemas match backend fixtures; malformed declarations fail clearly.
• Bare persistent mutable collections and unsupported Chain subjects are rejected.
• One documented Python example installs, invokes, mutates, restarts, and reads the same Service through local and HTTP backends.
• Typed backend/auth/dependency failures remain intact and framework-owned lifecycle details stay hidden.
• Existing Library and Class authoring remains compatible; shared helpers are reused.
• V1 adaptations and currently unsupported variants are documented without implying broader persistence support.

Focused tests for the ported behavior belong with implementation. Extensive security, performance, cross-adapter, and fault-injection validation may be deferred to pre-release testing as authorized; link outstanding scenarios to TinyChain-Inc/tcv2#70, TinyChain-Inc/tcv2#55, and TinyChain-Inc/tcv2#38. Do not mark deferred scenarios as passing.