Add server-side streaming support and improve documentation infrastructure (#52)

* extend transaction

* start transaction service

* start

* Add streaming support with base client integration across all SDKs

Implement production-ready streaming method support with proper validation,
authentication, timeout handling, and error management across Go, Java,
Python, and TypeScript SDKs.

Key changes:
- Go: Add ExecuteStream[T,R]() for streaming methods with validation, auth, timeout, tracing
- Java: Add executeStream() with validation, timeout, enhanced error context
- Python: Add _execute_streaming_method() with validation, auth metadata injection
- TypeScript: Add validateRequest() and manual metadata handling for streaming
- Update all code generators to use new streaming execution methods
- Regenerate SDKs to use ExecuteStream/executeStream/_execute_streaming_method

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

* Add server-side streaming support to protoc-gen-meshdoc

Implement streaming detection and documentation generation for gRPC
server-side streaming methods in the protoc-gen-meshdoc tool.

Changes:
- Add IsServerStreaming detection in parser using method.Desc.IsStreamingServer()
- Create streaming-specific templates for Go, Python, and Java
- Update template selection logic to route streaming methods correctly
- Enhance method documentation template with streaming semantics
- Regenerate MonitorTransactionState examples with proper streaming patterns

Features:
- Go streaming: stream.Recv() loop with io.EOF handling
- Python streaming: iterator pattern with for...in loop
- Java streaming: Iterator<Response> with hasNext()/next()
- Stream lifecycle documentation (initiation, data reception, completion)
- Clear distinction between stream errors and normal completion

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

* Fix documentation broken links by mapping footer to existing architecture files

Updated Docusaurus footer configuration to reference correct architecture documentation files:
- Group Ownership → resource-hierarchy.mdx
- Role-Based Access → method-permissions.mdx
- Client Structuring → legal-entities.mdx
- Authentication → api-access.mdx

Fixed internal cross-references within architecture docs to use correct file paths.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

* Upgrade Docusaurus to v3.9.1 and fix deprecated config warning

- Updated all Docusaurus packages from 3.8.1 to 3.9.1
- Migrated onBrokenMarkdownLinks from top-level config to markdown.hooks.onBrokenMarkdownLinks
- Eliminates deprecation warning about Docusaurus v4 compatibility
- Build completes successfully with no warnings

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

* Disable git-based last update metadata to eliminate build warnings

- Set showLastUpdateAuthor and showLastUpdateTime to false
- Eliminates "Cannot infer the update date for some files" warning
- Removes dependency on git history for documentation metadata
- Documentation pages will no longer show last update info

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

* Rename studio instrument type.proto to instrument_type.proto for clarity

Refactored protobuf file naming to be more descriptive:
- Renamed type.proto → instrument_type.proto in studio/instrument/v1
- Updated import in wallet/account proto to reference new filename
- Regenerated all SDK code (Go, Python, TypeScript) with updated imports

This makes the file purpose clearer and follows naming best practices
for protobuf definitions containing domain-specific types.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

---------

Co-authored-by: Claude <[email protected]>

Author: BRBussy

docs/docs/api-reference/ledger/transaction/v1/index.mdx

@@ -0,0 +1,43 @@
+---
+sidebar_position: 1
+---
+
+# Ledger Transaction v1 Service
+
+#### Skip The Details?
+- 👉 Jump to **[Package Types](/docs/api-reference/ledger/transaction/v1/type)**
+- 👉 Jump to **[Service Methods](/docs/api-reference/ledger/transaction/v1/service)**
+
+{/*
+Generated by protoc-gen-meshdoc the first time.
+-> This file can be edited manually to add information about the Ledger Transaction Service.
+
+THIS COMMENT AND EVERYTHING ABOVE IT IS AUTOGENERATED
+*/}
+
+:::warning[SDK and Documentation Under Construction 🚧]
+This warning will be removed once complete and ready for use.
+:::
+
+## Overview
+
+TransactionService manages Transaction lifecycle.
+
+Add your custom documentation for the Ledger Transaction v1 service here.
+This file is generated once and can be manually edited to provide
+service-specific information, examples, and usage guidance.
+
+## Quick Start
+
+1. **Configure your client** with the appropriate credentials
+2. **Choose your operations** from the available service methods
+3. **Review the types** to understand request/response structures
+
+## Common Workflows
+
+Add common workflow documentation here specific to this service.
+
+## Authentication & Authorization
+
+This service requires appropriate role-based permissions. 
+See the individual method documentation for specific role requirements.

docs/docs/api-reference/ledger/transaction/v1/service/get-transaction-state/example.go

@@ -0,0 +1,35 @@
+package main
+
+import (
+	"context"
+	"log"
+
+	transactionv1 "github.com/meshtrade/api/go/ledger/transaction/v1"
+)
+
+func main() {
+	ctx := context.Background()
+
+	// Default configuration is used and credentials come from MESH_API_CREDENTIALS
+	// environment variable or default discovery methods. Zero config required
+	// unless you want custom configuration.
+	service, err := transactionv1.NewTransactionService()
+	if err != nil {
+		log.Fatalf("Failed to create service: %v", err)
+	}
+	defer service.Close()
+
+	// Create request with service-specific parameters
+	request := &transactionv1.GetTransactionStateRequest{
+		// FIXME: Populate service-specific request fields
+	}
+
+	// Call the GetTransactionState method
+	response, err := service.GetTransactionState(ctx, request)
+	if err != nil {
+		log.Fatalf("GetTransactionState failed: %v", err)
+	}
+
+	// FIXME: Add relevant response object usage
+	log.Printf("GetTransactionState successful: %+v", response)
+}

docs/docs/api-reference/ledger/transaction/v1/service/get-transaction-state/example.java

@@ -0,0 +1,28 @@
+import co.meshtrade.api.ledger.transaction.v1.TransactionService;
+import co.meshtrade.api.ledger.transaction.v1.Service.GetTransactionStateRequest;
+import co.meshtrade.api.ledger.transaction.v1.Service.GetTransactionStateResponse;
+
+import java.util.Optional;
+
+public class GetTransactionStateExample {
+    public static void main(String[] args) {
+        // Default configuration is used and credentials come from MESH_API_CREDENTIALS
+        // environment variable or default discovery methods. Zero config required
+        // unless you want custom configuration.
+        try (TransactionService service = new TransactionService()) {
+            // Create request with service-specific parameters
+            GetTransactionStateRequest request = GetTransactionStateRequest.newBuilder()
+                // FIXME: Populate service-specific request fields
+                .build();
+
+            // Call the GetTransactionState method
+            GetTransactionStateResponse response = service.getTransactionState(request, Optional.empty());
+
+            // FIXME: Add relevant response object usage
+            System.out.println("GetTransactionState successful: " + response);
+        } catch (Exception e) {
+            System.err.println("GetTransactionState failed: " + e.getMessage());
+            e.printStackTrace();
+        }
+    }
+}

docs/docs/api-reference/ledger/transaction/v1/service/get-transaction-state/example.py

@@ -0,0 +1,27 @@
+from meshtrade.ledger.transaction.v1 import (
+    GetTransactionStateRequest,
+    TransactionService,
+)
+
+
+def main():
+    # Default configuration is used and credentials come from MESH_API_CREDENTIALS
+    # environment variable or default discovery methods. Zero config required
+    # unless you want custom configuration.
+    service = TransactionService()
+
+    with service:
+        # Create request with service-specific parameters
+        request = GetTransactionStateRequest(
+            # FIXME: Populate service-specific request fields
+        )
+
+        # Call the GetTransactionState method
+        response = service.get_transaction_state(request)
+
+        # FIXME: Add relevant response object usage
+        print("GetTransactionState successful:", response)
+
+
+if __name__ == "__main__":
+    main()

docs/docs/api-reference/ledger/transaction/v1/service/monitor-transaction-state/example.go

@@ -0,0 +1,49 @@
+package main
+
+import (
+	"context"
+	"io"
+	"log"
+
+	transactionv1 "github.com/meshtrade/api/go/ledger/transaction/v1"
+)
+
+func main() {
+	ctx := context.Background()
+
+	// Default configuration is used and credentials come from MESH_API_CREDENTIALS
+	// environment variable or default discovery methods. Zero config required
+	// unless you want custom configuration.
+	service, err := transactionv1.NewTransactionService()
+	if err != nil {
+		log.Fatalf("Failed to create service: %v", err)
+	}
+	defer service.Close()
+
+	// Create request with service-specific parameters
+	request := &transactionv1.MonitorTransactionStateRequest{
+		// FIXME: Populate service-specific request fields
+	}
+
+	// Call the MonitorTransactionState streaming method
+	stream, err := service.MonitorTransactionState(ctx, request)
+	if err != nil {
+		log.Fatalf("Failed to initiate stream: %v", err)
+	}
+
+	// Consume stream responses
+	for {
+		response, err := stream.Recv()
+		if err == io.EOF {
+			break // Stream completed normally
+		}
+		if err != nil {
+			log.Fatalf("Stream error: %v", err)
+		}
+
+		// Process each response as it arrives
+		log.Printf("Received: %+v", response)
+	}
+
+	log.Println("Stream completed successfully")
+}

docs/docs/api-reference/ledger/transaction/v1/service/monitor-transaction-state/example.java

@@ -0,0 +1,36 @@
+import co.meshtrade.api.ledger.transaction.v1.TransactionService;
+import co.meshtrade.api.ledger.transaction.v1.Service.MonitorTransactionStateRequest;
+import co.meshtrade.api.ledger.transaction.v1.Service.MonitorTransactionStateResponse;
+
+import java.util.Iterator;
+import java.util.Optional;
+
+public class MonitorTransactionStateExample {
+    public static void main(String[] args) {
+        // Default configuration is used and credentials come from MESH_API_CREDENTIALS
+        // environment variable or default discovery methods. Zero config required
+        // unless you want custom configuration.
+        try (TransactionService service = new TransactionService()) {
+            // Create request with service-specific parameters
+            MonitorTransactionStateRequest request = MonitorTransactionStateRequest.newBuilder()
+                // FIXME: Populate service-specific request fields
+                .build();
+
+            // Call the MonitorTransactionState streaming method
+            Iterator<MonitorTransactionStateResponse> stream = service.monitorTransactionState(request, Optional.empty());
+
+            // Consume stream responses using iterator pattern
+            while (stream.hasNext()) {
+                MonitorTransactionStateResponse response = stream.next();
+
+                // Process each response as it arrives
+                System.out.println("Received: " + response);
+            }
+
+            System.out.println("Stream completed successfully");
+        } catch (Exception e) {
+            System.err.println("MonitorTransactionState stream failed: " + e.getMessage());
+            e.printStackTrace();
+        }
+    }
+}

docs/docs/api-reference/ledger/transaction/v1/service/monitor-transaction-state/example.py

@@ -0,0 +1,35 @@
+from meshtrade.ledger.transaction.v1 import (
+    MonitorTransactionStateRequest,
+    TransactionService,
+)
+
+
+def main():
+    # Default configuration is used and credentials come from MESH_API_CREDENTIALS
+    # environment variable or default discovery methods. Zero config required
+    # unless you want custom configuration.
+    service = TransactionService()
+
+    with service:
+        # Create request with service-specific parameters
+        request = MonitorTransactionStateRequest(
+            # FIXME: Populate service-specific request fields
+        )
+
+        # Call the MonitorTransactionState streaming method
+        stream = service.monitor_transaction_state(request)
+
+        try:
+            # Consume stream responses using iterator pattern
+            for response in stream:
+                # Process each response as it arrives
+                print("Received:", response)
+
+            print("Stream completed successfully")
+        except Exception as e:
+            print("Stream error:", e)
+            raise
+
+
+if __name__ == "__main__":
+    main()

docs/docs/architecture/api-access.mdx

@@ -16,7 +16,7 @@ x-group: groups/{group_ulid}
 
 **Key Characteristics:**
 API keys are generated when creating API users.
-- See **[Introduction](/docs/architecture/group-ownership)** or **[IAM API User Service Reference](/docs/api-reference/iam/api_user/v1)** for more.
+- See **[Resource Hierarchy](/docs/architecture/resource-hierarchy)** or **[IAM API User Service Reference](/docs/api-reference/iam/api_user/v1)** for more.
 
 ### Group Context
 

docs/docs/architecture/legal-entities.mdx

@@ -7,9 +7,9 @@ Understanding how clients define legal entity boundaries within Mesh's hierarchi
 Clients in Mesh serve as **legal entity boundaries** that define where one legal entity ends and another begins within the hierarchical group structure. Each client represents a distinct legal entity (individual, company, fund, or trust) that has undergone compliance verification and establishes the scope of role assignments for users and API users operating within that entity's organizational structure.
 
 **The Three-Layer Architecture:**
-- **Groups** ([Group Ownership](./group-ownership)): Control resource ownership and access hierarchy
+- **Groups** ([Resource Hierarchy](./resource-hierarchy)): Control resource ownership and access hierarchy
 - **Clients** (this document): Define legal entity boundaries and available role types
-- **Roles** ([Role-Based Access](./role-based-access)): Control method-level API access permissions
+- **Roles** ([Role-Based Access Control](./method-permissions)): Control method-level API access permissions
 
 ## What are Clients?
 
@@ -605,14 +605,14 @@ Client verification status provides the compliance foundation for the entire org
 ## Related Documentation
 
 ### Core Architecture Components
-- **[Group Ownership Structure](./group-ownership)** - Understanding the hierarchical resource ownership system that provides the foundation for client positioning
-- **[Role-Based Access Control](./role-based-access)** - Understanding the role system that clients control and how method-level permissions work
+- **[Resource Hierarchy](./resource-hierarchy)** - Understanding the hierarchical resource ownership system that provides the foundation for client positioning
+- **[Role-Based Access Control](./method-permissions)** - Understanding the role system that clients control and how method-level permissions work
 
 ### API Reference Documentation
 - **[Compliance Client Service API Reference](/docs/api-reference/compliance/client/v1)** - Complete API documentation for client management operations and legal entity types
 - **[IAM Group Service API Reference](/docs/api-reference/iam/group/v1)** - Complete API documentation for group management operations that own clients
 - **[IAM API User Service Reference](/docs/api-reference/iam/api_user/v1)** - Complete API documentation for managing API users and role assignments within client boundaries
 
 ### Implementation Guides
-- **[Authentication](./authentication)** - API key and group context authentication mechanisms that work with client role boundaries
+- **[Authentication](./api-access)** - API key and group context authentication mechanisms that work with client role boundaries
 - **[Service Structure](./service-structure)** - Understanding API organization and method patterns that clients control access to

docs/docs/architecture/method-permissions.mdx

@@ -8,7 +8,7 @@ Role-Based Access Control (RBAC) in Mesh operates as a **two-layer security mode
 
 **The Dual Authorization Model:**
 - **Roles** (this document): Control method-level access to API operations
-- **Groups** ([Group Ownership](./group-ownership)): Control resource-level access through ownership hierarchy
+- **Groups** ([Resource Hierarchy](./resource-hierarchy)): Control resource-level access through ownership hierarchy
 
 Our guiding principle is using the **Protobuf schema as the single source of truth** for all authorization rules, ensuring our security model is self-documenting, automatically verifiable, and always in sync with the API contract.
 
@@ -388,8 +388,8 @@ graph LR
 
 ## Related Documentation
 
-- **[Group Ownership Structure](./group-ownership)** - Understanding the resource ownership and hierarchy system that works with roles
-- **[Authentication](./authentication)** - API key and group context authentication mechanisms  
+- **[Resource Hierarchy](./resource-hierarchy)** - Understanding the resource ownership and hierarchy system that works with roles
+- **[Authentication](./api-access)** - API key and group context authentication mechanisms  
 - **[Service Structure](./service-structure)** - Understanding API organization and method patterns
 - **[IAM API User Service Reference](/docs/api-reference/iam/api_user/v1)** - Complete API documentation for managing API users and role assignments
 - **[IAM Group Service Reference](/docs/api-reference/iam/group/v1)** - Complete API documentation for group management operations