Refresh codebase wiki (#7466)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

doc/wiki/diagnostics-console-logs.md

@@ -118,3 +118,8 @@ app.UseConsoleLogs();
 ## Design Spec
 
 [specs/006-diagnostics-console-logs/spec.md](../../specs/006-diagnostics-console-logs/spec.md) defines requirements for capture, buffering, endpoints, SignalR, permissions, source identity, and redaction.
+
+## Tests
+
+- [test/unit/Elsa.Diagnostics.ConsoleLogs.UnitTests](../../test/unit/Elsa.Diagnostics.ConsoleLogs.UnitTests): capture, filtering, redaction, buffering, source registry, and naming.
+- [test/integration/Elsa.Diagnostics.ConsoleLogs.IntegrationTests](../../test/integration/Elsa.Diagnostics.ConsoleLogs.IntegrationTests): module registration, endpoint authorization, SignalR hub behavior, and recent query endpoint.

doc/wiki/testing-guide.md

@@ -31,6 +31,7 @@ Shared helpers:
 | EF Core store or migration | Provider-specific integration/component test. |
 | HTTP workflows | Component test under HTTP workflow scenarios. |
 | Structured log SQLite persistence | SQLite integration test project. |
+| Console log capture, buffering, or endpoints | `Elsa.Diagnostics.ConsoleLogs.UnitTests` or `Elsa.Diagnostics.ConsoleLogs.IntegrationTests`. |
 
 ## Useful Commands
 
@@ -118,13 +119,22 @@ Use component tests when host lifecycle, HTTP server behavior, actual persistenc
 
 Structured log tests are split by layer:
 
-- core module unit tests
-- core module integration tests
-- relational unit tests
-- SQLite integration tests
+- [test/unit/Elsa.Diagnostics.StructuredLogs.UnitTests](../../test/unit/Elsa.Diagnostics.StructuredLogs.UnitTests)
+- [test/integration/Elsa.Diagnostics.StructuredLogs.IntegrationTests](../../test/integration/Elsa.Diagnostics.StructuredLogs.IntegrationTests)
+- [test/unit/Elsa.Diagnostics.StructuredLogs.Persistence.Relational.UnitTests](../../test/unit/Elsa.Diagnostics.StructuredLogs.Persistence.Relational.UnitTests)
+- [test/integration/Elsa.Diagnostics.StructuredLogs.Persistence.Sqlite.IntegrationTests](../../test/integration/Elsa.Diagnostics.StructuredLogs.Persistence.Sqlite.IntegrationTests)
 
 This mirrors the architecture: core capture and API behavior should not require SQLite; SQLite tests should prove durability, migrations, retention, timestamp storage, queue overflow, and filtering.
 
+## Console Log Tests
+
+Console log tests are split by layer:
+
+- [test/unit/Elsa.Diagnostics.ConsoleLogs.UnitTests](../../test/unit/Elsa.Diagnostics.ConsoleLogs.UnitTests): capture, filtering, redaction, buffering, source registry, and naming.
+- [test/integration/Elsa.Diagnostics.ConsoleLogs.IntegrationTests](../../test/integration/Elsa.Diagnostics.ConsoleLogs.IntegrationTests): module registration, endpoint authorization, SignalR hub, and recent query behavior.
+
+Run targeted console log tests when touching `Elsa.Diagnostics.ConsoleLogs`.
+
 ## Good Test Hygiene
 
 - Prefer targeted project tests while iterating.

doc/wiki/workflow-core.md

@@ -42,6 +42,7 @@ Built-in activities live in [Activities](../../src/modules/Elsa.Workflows.Core/A
 - Data and runtime helpers: `SetVariable`, `SetName`, `Correlate`, `WriteLine`, `ReadLine`.
 - Dynamic and missing activity handling: `DynamicActivity`, `NotFoundActivity`.
 - Flowchart: [Activities/Flowchart](../../src/modules/Elsa.Workflows.Core/Activities/Flowchart/Activities).
+- State machine: [Activities/StateMachine](../../src/modules/Elsa.Workflows.Core/Activities/StateMachine/Activities). Named states with trigger-driven transitions. See [Activities And Authoring](activities-and-authoring.md) for the execution model.
 
 Activities are described by `IActivityDescriber` and registered in `IActivityRegistry`. Workflow management adds activities to the available designer/API surface.