`aw.yml` package manifests can list installable workflows that other repositories add via `gh aw add` / `gh aw add-wizard`. The `private` frontmatter field was designed to block a standalone workflow from being installed elsewhere (`private: true`), but the manifest resolution path only consulted `ExtractWorkflowPrivate`, which returned `false` for both an absent field and an explicit `private: false`. As a result, a manifest could list a workflow declaring `private: false`, and that declaration would silently pass — leaking an installation-control field into package manifests where it has no coherent meaning. A workflow that is listed in a manifest is, by definition, meant to be installed, so any `private` declaration on it (true *or* false) is contradictory and should be surfaced rather than ignored.

We will treat the presence of a `private` field on a manifest-listed installable workflow as a manifest validation error, distinguishing presence from value. We split `ExtractWorkflowPrivate(content) bool` into a presence-aware `ExtractWorkflowPrivateSetting(content) (value, present bool)`, keeping `ExtractWorkflowPrivate` as a thin wrapper for the existing standalone-add behavior. Both manifest-backed resolution (`ResolveWorkflows` for `FromRepositoryManifest` specs) and compile-time local manifest validation (`validateLocalRepositoryPackageContents`) now reject any listed workflow that declares `private`, emitting manifest-scoped errors that name the offending workflow path: `private: true` reports that private workflows cannot be added, and `private: false` instructs the author to remove the field.

Continue using the boolean-only `ExtractWorkflowPrivate` and reject manifest workflows only when it returns `true`. This was rejected because it cannot distinguish an absent field from `private: false`, so the originally-reported leak (`private: false` slipping into a manifest) would remain silently accepted, and authors would get no signal that the field is meaningless in a manifest context.

Silently drop the `private` field when resolving manifest workflows so installation proceeds regardless. This was rejected because silent normalization hides author intent and conflicts with the project's fail-loud manifest-validation posture; an explicit, path-scoped error is more debuggable and prevents shipping manifests that encode contradictory intent.

- Closes the leak where `private: false` in a manifest-listed workflow was silently accepted; the field is now rejected at both add time and compile time.

- Error messages are presence- and value-aware and name the offending workflow path, making the fix obvious to manifest authors.

- Existing published manifests that list workflows carrying any `private` declaration will now fail to add/compile until the field is removed — a breaking change for those packages.

- Introduces a second extraction function (`ExtractWorkflowPrivateSetting` alongside `ExtractWorkflowPrivate`) and parallel rejection logic in both the resolution and compile-time paths that must stay in sync.

- Compile-time validation now scans manifest-listed installable paths (explicit `files:`/`includes:` entries, or discovered package directories) to apply the rule uniformly.