Rename authoring super-skill al-feature-author -> al-code-author

Naming/framing change only - the authoring counterpart to al-code-review is
now the role-level al-code-author. The Action/Output substance is unchanged:
the decompose -> per-object fan-out -> roll up -> reconcile logic and the
Membership worked example stay exactly as they were and correctly describe the
skill's current mode (greenfield feature authoring).

- git mv al-feature-author.md -> al-code-author.md; id al-code-author,
  title "AL code author", reframed description. Intro now states the role
  (authoring counterpart to al-code-review, produces a whole PR of code) and
  is honest that greenfield feature authoring is its first and currently only
  mode (other modes such as defect-fix-from-bug-report are future extensions).
  inputs [feature-spec], outputs [code-artifact], sub-skills [al-api-page-author,
  al-table-author] and dimension fields all unchanged.
- skills/do.md: one-word consistency tweak in the Composition Relevance example
  (a feature author -> a code author). Behavior-preserving; the findings/Action
  rollup path is byte-identical.
- README.md, agent-consumption.md: author family's top-level skill is now
  al-code-author.

R26 generalization and the al-table-author leaf from #67 are unchanged.
Knowledge article count unchanged at 199.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

skills/do.md

@@ -299,7 +299,7 @@ Composition is flat: a super-skill MAY list only leaf skills (skills without the
 The five required sections still apply. Their meaning shifts from knowledge files to sub-skills:
 
 - `## Source` — names the sub-skills invoked (mirrors `sub-skills` in frontmatter).
-- `## Relevance` — rules for deciding which sub-skills apply to the current task. A sub-skill is relevant when its declared `inputs` are satisfied — either directly by the orchestrator's provided inputs, or by inputs the super-skill itself will supply by decomposing its own input — and the orchestrator has not disabled it via configuration. A super-skill's own `inputs` need not equal its leaves' `inputs`; when they differ (for example, a feature author declares `inputs: [feature-spec]` while its leaves declare `inputs: [object-spec]`), the super-skill's `## Action` decomposes its own input into the inputs its leaves require, and relevance is judged against those derived inputs. The super-skill MUST NOT filter sub-skills by task content (for example, by inspecting the diff or the file). Task-level applicability is the sub-skill's own responsibility; sub-skills signal non-applicability by returning `outcome: "not-applicable"` or `outcome: "no-knowledge"`.
+- `## Relevance` — rules for deciding which sub-skills apply to the current task. A sub-skill is relevant when its declared `inputs` are satisfied — either directly by the orchestrator's provided inputs, or by inputs the super-skill itself will supply by decomposing its own input — and the orchestrator has not disabled it via configuration. A super-skill's own `inputs` need not equal its leaves' `inputs`; when they differ (for example, a code author declares `inputs: [feature-spec]` while its leaves declare `inputs: [object-spec]`), the super-skill's `## Action` decomposes its own input into the inputs its leaves require, and relevance is judged against those derived inputs. The super-skill MUST NOT filter sub-skills by task content (for example, by inspecting the diff or the file). Task-level applicability is the sub-skill's own responsibility; sub-skills signal non-applicability by returning `outcome: "not-applicable"` or `outcome: "no-knowledge"`.
 - `## Worklist` — the final list of sub-skills to invoke; the rest go to `skipped-sub-skills`.
 - `## Action` — invoke each worklisted sub-skill with the appropriate subset of inputs (a super-skill whose `inputs` differ from its leaves' derives those leaf inputs here), collect its report verbatim into `sub-results`, and roll its results up into the super-skill's top-level list according to the output kind. For a `findings-report`, copy its `findings[]` into the super-skill's top-level `findings[]` with `from-sub-skill` set. For a `code-artifact`, copy its `artifacts[]` into the super-skill's top-level `artifacts[]` (the `code-artifact` schema has no per-artifact `from-sub-skill` field, so leaf attribution is preserved through `sub-results`). In both cases a sub-skill with `outcome: "failed"` contributes nothing to the super-skill's top-level list (`findings[]` or `artifacts[]`) and MUST NOT contribute to the super-skill's `summary.counts` (its report is still preserved in `sub-results` for traceability, consistent with DO's rule that consumers ignore a failed skill's output).
 - `## Output` — the super-skill's output contract, including `sub-results` and, if any, `skipped-sub-skills`.