docs: add AUDIENCES.md per audience-identification spec

[nolte]

Summary

Apply spec/project/audience-identification/ to this repository for the
first time and persist the resulting audience list at AUDIENCES.md at the
repo root (the spec's canonical default location). The artifact is the
prerequisite for the planned audience-doc-author refactor of README.md
and docs/modules/*.md, and unblocks every downstream spec that references
an audience list (readme-structure, release-notes-audience-analysis,
release-skill-layer, future SLA or threat-model specs).

Changes

• Add AUDIENCES.md at the repository root with:
  • A written bounded context (in scope / out of scope), declared before any
    audience is listed, per spec §Requirements.
  • One audience under Direct consumers (Taskfile-consumer project,
    assumed, primary).
  • Two audiences under Operators (consumer-side developer, primary;
    consumer-side CI, secondary), both assumed.
  • Two audiences under Contributors / maintainers (module maintainer,
    primary; documentation author, secondary), both assumed.
  • Two audiences under Governing parties (nolte portfolio architecture
    conventions, primary; Renovate / dependency-pinning governance,
    secondary), both confirmed.
  • Indirect audiences explicitly recorded as none — purely developer tooling, every affected person already covered under Operators or Direct consumers.
• Every audience entry carries label, category, surface, expects,
  track, status, criticality, and open questions, as the spec
  requires.
• All six audiences map to developer-docs; the artifact explicitly states
  the repository has no user-docs audience and why.

Linked issues

Refs spec/project/audience-identification/

Testing

• audience-identify skill (operation run) drove the artifact end-to-end:
  bounded context declared first, each of the five relationship categories
  surfaced separately, confirmed only set after explicit confirmation in
  the conversation.
• Manual check against the spec's Acceptance Criteria:
  • Bounded context declared before any audience is listed.
  • All five relationship categories addressed (Indirect = none with
    reason).
  • Every entry has label, category, surface, expectation, track,
    status, open questions, criticality.
  • Every entry tagged confirmed or assumed.
  • Artifact lives at AUDIENCES.md at the bounded-context root.

Risk / rollout notes

Low risk — AUDIENCES.md is a documentation artifact with no runtime or CI
behaviour. The primary open question (concrete identity of the Taskfile
consumers) is recorded inline so the Direct-consumer entry can be promoted
from assumed to confirmed later without rewriting the file.

Two assumed clusters are worth surfacing for follow-up:

• Consumer identity is unknown today; until at least one downstream repo
  cites this collection by name, Direct consumers stays assumed.
• Operator / contributor audiences are author-inferred from CLAUDE.md and
  the repo's PR history; a one-paragraph note from any real maintainer
  besides the repo owner would let those flip to confirmed.