release-* family has no ASF incubator/podling handling (IPMC vote, DISCLAIMER, incubator dist paths, -incubating suffix)

I got Claude AI to raise this. I have checked the text for obvious mistakes but apologies if there are things that I missed.

### What should happen

The `release-*` skill family should recognise ASF **incubator podlings** as a
distinct project stage and adapt its vote, promote, verify, and announce
behaviour accordingly — the way `committer-onboarding` already forks on
incubating vs graduated.

### Why

The framework already models the concept but the release family does not
consume it:

- `organizations/ASF/organization.md:80` declares
`project_stage_vocab: [incubating, top-level]`, resolving the
`` placeholder documented at `AGENTS.md:396`.
- `skills/committer-onboarding/SKILL.md:118` (Golden rule 5) explicitly forks
the incubating and graduated paths, asks which applies, and adapts every
subsequent instruction.

But grepping `incubat|podling|IPMC|general@incubator` across all ten
`skills/release-*/` directories, `docs/release-management/`, and
`projects/_template/release-management-config.md` returns **zero matches**. A
podling Release Manager running this family today gets guidance that is wrong
in at least six places:

| Gap | Where | Current behaviour |
|---|---|---|
| Second IPMC vote on `general@incubator.apache.org` after the PPMC vote passes | `release-vote-draft`, `release-vote-tally` | Single-stage vote only. `skills/release-vote-tally/SKILL.md:360` hardcodes `pass = (binding_plus1 >= 3) AND (binding_plus1 > binding_minus1)` against `/pmc-roster.md` — no IPMC roster, no second round |
| `dist/dev/incubator//` and `dist/release/incubator//` paths | `release-prepare`, `release-promote`, `release-archive-sweep` | All assume `dist/{dev,release}//` |
| PPMC vs IPMC write gate | `skills/release-promote/SKILL.md:107` (Golden rule 5) | Checks `pmc-roster.md` only; a podling RM's promote is gated by the IPMC, not the PPMC |
| Mandatory `DISCLAIMER` / `DISCLAIMER-WIP` file in the source artefact | `release-verify-rc` | Checks LICENSE / NOTICE / RAT / prohibited binaries — no DISCLAIMER check |
| `-incubating` version-string suffix | `release-verify-rc` version-consistency check, `release-rc-cut` tag | Not recognised |
| Podling announcement rules | `release-announce-draft`, `projects/_template/release-management-config.md` | The template already says `announce@apache.org` is "mandatory for ASF **TLP** releases" — the TLP qualifier is correct, but nothing supplies the podling equivalent |

These are policy requirements from
[the Incubator release-management guide](https://incubator.apache.org/guides/releasemanagement.html)
and
[the Incubator branding/DISCLAIMER rules](https://incubator.apache.org/guides/branding.html),
not stylistic preferences — a podling release that skips the IPMC vote or the
DISCLAIMER file is invalid.

### Which layer

Skill (`.claude/skills//`)

### Boundary conditions

- **Stage unset.** When no `project_stage` is configured, the skills must
behave exactly as they do today (top-level). No silent podling assumptions.
- **Non-ASF adopters.** `release-promote` already has `--non-asf` to skip PMC
concepts. Podling handling must sit behind the ASF organization adapter and
stay invisible to independent-governance adopters, whose
`project_stage_vocab` is `[]`.
- **Graduation mid-release-train.** A project that graduates between RCs will
have `-incubating` in an already-published version and not in the next. The
skills should read the stage per invocation rather than caching it across a
train, and `release-archive-sweep` must still recognise archived
`-incubating` versions under the old `incubator/` dist path.
- **Vote-stage ambiguity in `release-vote-tally`.** With two sequential vote
threads, the skill needs to know which one it is tallying; it should not
merge PPMC and IPMC votes into one count.
- **`release_vote_backend = atr`.** Whether ATR models the two-stage podling
vote at all is unknown — worth confirming before wiring, rather than
assuming the `manual` shape.

### Out of scope

- Graduation itself (board resolution, `committee-info.txt`, TLP rename) —
that is governance, not release management.
- Changing the existing 3-binding-`+1` pass rule for top-level projects. This
proposal adds a second stage for podlings; it does not weaken the baseline.
- Podling-specific handling in the `security-*` family.

### References

- `organizations/ASF/organization.md:80` — `project_stage_vocab`
- `AGENTS.md:396` — `` placeholder resolution order
- `skills/committer-onboarding/SKILL.md:118` — the incubating/graduated fork to
mirror
- `skills/release-vote-tally/SKILL.md:352-360` — pass-rule evaluation
- `skills/release-promote/SKILL.md:107` — PMC membership gate
-
- (DISCLAIMER rules)

Cheapest route is probably a `project_stage` key in
`release-management-config.md` plus a committer-onboarding-style golden rule in
`release-vote-draft`, `release-vote-tally`, `release-promote`, and
`release-verify-rc`.

Start with organizations/ASF/organization.md, AGENTS.md, committer-onboarding/SKILL.md, and the cited release skill sections, then inspect release-management-config.md and the ATR backend behavior. Map project_stage handling across vote, promotion, verification, announcement, and archive paths. Done means podling and top-level behavior satisfy the stated boundaries without changing non-ASF or existing top-level rules.

Written by the indexing model from the issue text.