Spec inconsistency: §10.3 says the inline computation is a fenced code block, but §10.2's example indents it

[ojhermann]

Summary

§10.3 says an Attested Computation may carry its computation inline as "a single fenced code block in the body under # Computation." But §10.2's own worked example puts the computation in a 4-space-indented code block, not a fence:

# Computation
    SELECT SUM(amount) AS revenue
    FROM finance.recognized_revenue
    WHERE fiscal_year = @year

A consumer that detects the inline computation by looking for a fenced block under # Computation — the literal §10.3 wording — would miss the spec's own example, and for the §10.3 "inline or a computation: path" rule would wrongly conclude the computation is provided in neither place.

The question

Should §10.3 read "a fenced or indented code block," or should §10.2's example be rewritten as a fenced block? Either resolves it — the mismatch between the normative text and the worked example is the problem.

Context

Same shape as #234 (the actor convention): the normative text and a worked example disagree, so a strict reading of one flags the other. This surfaced building the same structural validator; we currently key the inline-vs-path check on the presence of the # Computation heading rather than the code block's style, so both forms pass.