docs(plans): type S22's reconciliation trigger step feat

What this changes

Step 15's card in the S22 plan said chore, and the step ships surface an operator can see. wireAccounting registers both reconciliation periodic kinds unconditionally, behind no feature flag and no configuration gate. A pod booting on that step starts walking namespaces and stamping namespace_statistics rows. That is the plan's own feat criterion, and it is the same reason Step 16's reconciliation_backlog collector is typed feat.

Four edits, all in docs/plans/2026-08-04-s22-storage-accounting.md:

1. Step 15's - **Type:** field moves from chore to feat.
2. The Type prefixes paragraph names the reconciliation trigger in its feat enumeration, and says on what criterion.
3. The paragraph gives Step 7 its own sentence, because Step 7 is feat on a different criterion. See the Step 7 is feat on the label taxonomy, not on operator visibility section.
4. The paragraph's two counts are corrected.

The counts were already wrong

The paragraph said "twelve of the twenty-one MRs are chore" and "an issue showing nine of twenty-one". Reading the - **Type:** field on all 21 step cards, the split before this change was eleven chore and ten feat, not twelve and nine. Step 7, batched guarded counter UPDATE, carries - **Type:** feat`` and the paragraph never named it.

This change names Step 7 in the paragraph and moves Step 15, so the split is now ten chore and eleven feat, and both numbers are corrected against the cards rather than against the old prose. The off-by-one predates this change; it is corrected here because retyping Step 15 would otherwise take the sentence from wrong by one to wrong by two.

Step 7 is feat on the label taxonomy, not on operator visibility

The paragraph's criterion is "steps that ship surface an operator can see", and Step 7 does not meet it. As it merged in 05bf33d7f, internal/datastore/counter_drain.go registered no metric, wrote no log line, and had no caller until Step 8. MaxCounterDrainBatchSize is not an exception to that: maxSADrainChunkSize = 850 predates 05bf33d7f, and that commit added only a compile-time assertion over the value the constant already held, so the drain_chunk_size range an operator can set is unchanged.

Step 7 is feat on the other criterion this project states. docs/dev/labels.md defines type::feature as "New capabilities or enhancements to existing ones", and a new exported datastore store is a new capability under that rule. !1511 (merged) settled that reading when it merged the step, in note 3688210221, and the same note recorded that the plan-internal inconsistency needed no action on a step MR. Guardrail 4 is the reason a step MR could not act on it, so this docs(plans) MR is where the record lands.

Step 7 therefore leaves the lead enumeration and takes its own sentence, in the shape this MR already used for the reconciliation trigger. The lead criterion sentence is unchanged, and it now covers the ten steps the enumeration names. The new sentence sits after the reconciliation trigger's sentence, so that "that same criterion" keeps pointing at the lead one.

Why this is its own MR

Guardrail 4 in AGENTS.md gives the plan file a single writer:

Step MRs do not edit the plan file, the Status table included. [...] fill the MR references in batch from a dedicated docs(plans) branch, or maintain them in one standing table MR while a workstream has steps in flight.

No open docs(plans) MR targets the S22 plan, so this is a new one rather than an addition to a standing MR.

The step MR that prompted it is !1803 (merged), which carries no plan edit of its own. Its title moves to feat(accounting) in that MR.

Scope

Documentation only. No code, no schema, no configuration. The ## Status table is untouched, so this does not collide with a batch fill.