docs: fix broken intra-doc links in sdk-reference

Fixes #167

zensical build --clean surfaced 19 validation warnings from stale
links in docs/sdk-reference/. Root causes:

- Singular vs plural filename: links pointed at steps.md,
  callbacks.md, child-contexts.md, but the actual files are
  step.md, callback.md, child-context.md.
- Stale paths from an earlier reorganization:
    ../advanced/error-handling.md -> ../error-handling/errors.md
    ../../testing/basic-tests.md -> ../../testing/index.md
    ../getting-started.md         -> ../../getting-started/index.md
    error-handling.md (bare)      -> ../error-handling/errors.md
- Anchor slug drift: retries.md linked to
  #retrying-specific-errors, but the heading is "Retry only specific
  errors", which slugifies to retry-only-specific-errors.

Also align step.md's top-level heading with the filename and with
the other singular operations (# Steps -> # Step).

Verified with zensical build --clean:
  before: 19 issues found
  after:  No issues found

Author: yaythomas

docs/sdk-reference/error-handling/retries.md

@@ -108,7 +108,7 @@ ready-made retry strategy from configuration.
     - `jitter` A `JitterStrategy` value: `FULL`, `HALF`, or `NONE`.
 
     Java does not have built-in error type filtering. Filter by error type manually inside
-    the `RetryStrategy` lambda. See [Retrying specific errors](#retrying-specific-errors).
+    the `RetryStrategy` lambda. See [Retrying specific errors](#retry-only-specific-errors).
 
 #### JitterStrategy
 

docs/sdk-reference/observability/logging.md

@@ -403,5 +403,5 @@ structured logger that works as a drop-in replacement for the SDK's default logg
 ## See also
 
 - [Steps](../operations/step.md)
-- [Child contexts](../operations/child-contexts.md)
-- [Error handling](error-handling.md)
+- [Child contexts](../operations/child-context.md)
+- [Error handling](../error-handling/errors.md)

docs/sdk-reference/operations/child-context.md

@@ -319,6 +319,6 @@ them to verify the child context ran and produced the expected result.
 
 ## See also
 
-- [Steps](steps.md) Run a single function with automatic checkpointing
+- [Steps](step.md) Run a single function with automatic checkpointing
 - [Parallel operations](parallel.md) Execute operations concurrently
 - [Map operations](map.md) Run operation for each item in a collection

docs/sdk-reference/operations/map.md

@@ -686,5 +686,5 @@ operations. Each nested map creates its own set of child contexts.
 
 - [Parallel operations](parallel.md) execute different functions concurrently
 - [Child contexts](child-context.md) understand child context isolation
-- [Steps](steps.md) use steps within map functions
-- [Error handling](../advanced/error-handling.md) in durable functions
+- [Steps](step.md) use steps within map functions
+- [Error handling](../error-handling/errors.md) in durable functions

docs/sdk-reference/operations/parallel.md

@@ -733,5 +733,5 @@ Each nested parallel creates its own set of child contexts.
 
 - [Map operations](map.md) run the same function concurrently on a collection
 - [Child contexts](child-context.md) understand child context isolation
-- [Steps](steps.md) use steps within parallel branches
-- [Error handling](../advanced/error-handling.md) in durable functions
+- [Steps](step.md) use steps within parallel branches
+- [Error handling](../error-handling/errors.md) in durable functions

docs/sdk-reference/operations/step.md

@@ -1,4 +1,4 @@
-# Steps
+# Step
 
 ## Checkpointed results
 
@@ -428,6 +428,6 @@ concurrent code path.
 ## See also
 
 - [Retries](../error-handling/retries.md)
-- [Testing](../../testing/basic-tests.md)
+- [Testing](../../testing/index.md)
 - [Wait operations](wait.md)
 - [Child contexts](child-context.md)

docs/sdk-reference/operations/wait-for-condition.md

@@ -4,7 +4,7 @@
 
 The Wait for Condition operation polls a check function on a schedule until your code
 signals it to stop. Behind the scenes, the check condition runs as a
-[durable step](steps.md), and each polling attempt is a retry, so the SDK checkpoints
+[durable step](step.md), and each polling attempt is a retry, so the SDK checkpoints
 results automatically and tracks state between attempts. The function suspends between
 attempts and does not consume Lambda execution time.
 
@@ -16,7 +16,7 @@ you need to poll an external system until something changes, like a batch job
 completing, a resource becoming available, or a status reaching a terminal state.
 
 If the external system will send a notification or response, use
-[Callbacks](callbacks.md) instead to suspend the durable function until it receives the
+[Callbacks](callback.md) instead to suspend the durable function until it receives the
 response.
 
 ## Walkthrough
@@ -181,6 +181,6 @@ Lambda cold start time, and current system load.
 ## See also
 
 - [Wait operations](wait.md) - Simple time-based delays
-- [Callbacks](callbacks.md) - Wait for external system responses
-- [Steps](steps.md) - Execute business logic with automatic checkpointing
-- [Getting Started](../getting-started.md) - Learn the basics of durable functions
+- [Callbacks](callback.md) - Wait for external system responses
+- [Steps](step.md) - Execute business logic with automatic checkpointing
+- [Getting Started](../../getting-started/index.md) - Learn the basics of durable functions

docs/sdk-reference/operations/wait.md

@@ -21,7 +21,7 @@ You cannot cancel a wait after it has started.
 ## When to use wait
 
 Use `context.wait()` for a time-based delay. For example, use waits between
-[steps](steps.md) to delay the new next step in multi-step workflows.
+[steps](step.md) to delay the new next step in multi-step workflows.
 
 ### Wait for an event or status change
 
@@ -32,7 +32,7 @@ alternatives:
     - [Wait for Condition](wait-for-condition.md) handles the polling loop, state
         tracking, and backoff for you.
 - **Waiting for an external system response**
-    - [Callbacks](callbacks.md) suspend your durable function until an external system
+    - [Callbacks](callback.md) suspend your durable function until an external system
         sends a response.
 
 ## Wait walkthrough
@@ -260,7 +260,7 @@ You can verify wait operations in your tests by inspecting the operations list:
 
 ## See also
 
-- [Steps](steps.md) - Execute business logic with automatic checkpointing
+- [Steps](step.md) - Execute business logic with automatic checkpointing
 - [Wait for Condition](wait-for-condition.md) - Poll until a condition is met
-- [Callbacks](callbacks.md) - Wait for external system responses
-- [Getting Started](../getting-started.md) - Learn the basics of durable functions
+- [Callbacks](callback.md) - Wait for external system responses
+- [Getting Started](../../getting-started/index.md) - Learn the basics of durable functions