[P2] Normalize shared plugin description metadata once instead of repeating it in every host block

[ScriptedAlchemy]

Authoring problem / inspected implementation

Audited 14c9822bc6c01d8ff2788454d0e1dc7861bc3816. Source-only design review, not a claim of broken native loading. This is a bounded simplification of composite authoring; #745 owns target discovery, #750 distribution, and #751 the documentation journey.

An ordinary multi-host plugin has one author/team, homepage, repository, license and set of discovery tags. Today those values are authored under different native/portable extension blocks. Adding a host repeats package-description metadata along with the few fields that are genuinely host-specific.

The current plugin config type models shared name/description/logo/version, while plugin-identity.ts already establishes package identity/version once. The portable metadata planner reads author/homepage/repository/license/keywords specifically from model.extensions.portable.value. Native projections independently read their native extension fields.

Desired ordinary path

Declare safe common descriptive metadata once, then let each existing adapter project only fields its host supports. Prefer reusing the package metadata already available during normalization rather than adding a new required file or a parallel descriptor registry. If explicit shared config overrides are needed, keep them on the existing plugin identity/config surface with clear precedence.

A consumer-level shared constant is a useful interim cleanup, but it still makes each author learn which host blocks accept which spelling. The framework should own that stable mapping.

Constraints / decisions

• Package name and plugin slug remain distinct; do not undo feat(codex): validate bundles against pinned schemas with honest host-devtools evidence (#133) #326-style identity separation or force one naming convention everywhere.
• Explicit native metadata wins over a shared default. Deliberate host-specific descriptions, absent fields and opt-outs must remain expressible.
• A marketplace owner is not automatically the plugin author. Native capabilities, trust declarations, hook registrations, interface hints and client extension namespaces are NOT common descriptive metadata.
• Do not copy arbitrary package.json fields into host manifests. Use a narrow allowlist and native schema validation.
• Package author string/object and repository string/object forms need a documented supported conversion or clear diagnostic. Reuse existing package/metadata parsing; no speculative URL normalizer or GitHub-specific rewrite framework.
• Include the actual source of normalized values in existing provenance/digests so editing package metadata invalidates the relevant output.

Acceptance

• A small composite fixture declares shared metadata once and emits correct supported values for the selected native and portable projections.
• Adding/removing/reordering a target does not require duplicating identity data or change another target's effective metadata.
• Native overrides and deliberate absence behave predictably; unsupported native fields are not invented.
• Invalid metadata produces an actionable source-linked diagnostic before publication, using existing native validators.
• Changing package metadata triggers the existing rebuild path and produces the expected artifact/inventory change without touching unrelated content.
• Packed/relocated output preserves the same descriptive information; no runtime package discovery is introduced.
• Simplify an actual consumer config as proof: remove repeated values rather than add another wrapper around them.
• Update the reference once and show the small default path first; do not require an author to read every host spec to publish basic metadata.

Non-goals

No new capability registry, user identity inference, account lookup, secret/configuration propagation, automatic publication, or claim of support for a host solely because descriptive metadata can be emitted. This is a build-time default/projection change with native escape hatches, not a new runtime subsystem.

[ScriptedAlchemy]

Taking this one. Recording the seam and the intended shape before writing code, since the
constraint list here rules out most of the obvious implementations.

Where the duplication actually is, on b0b25d3b13: three host blocks each accept the same five
descriptive fields, and each validates them against its own pinned schema —
portable.{author,homepage,repository,license,keywords}
(adapters/portable.ts, planPortableManifestMetadata), cursor.* the same five plus
category/publisher/tags (adapters/cursor.ts), and
claude.marketplace.plugin.* (adapters/claude.ts, marketplacePluginFields). Amp and Codex
project none of them, so this is a three-host projection, not five.

The reuse point the issue asks for already exists: snapshotPackageIdentity in
core/project-context.ts reads <root>/package.json once and returns name/version plus
structured issues, and config/plugin-identity.ts turns that into the one identity
normalizeProject stamps into model.metadata. Shared descriptive metadata belongs on that
same read — a narrow allowlist beside the identity fields — not in a new file, descriptor
registry, or config key that duplicates package.json.

Planned shape:

• Extend the existing package-document read with the allowlisted descriptive fields, normalized
  once: npm's author string (Name <email> (url)) or object to {name,email,url};
  repository string or {url} object to an absolute URL, with git+https://…​.git documented
  as the one accepted conversion and anything else a source-linked diagnostic rather than a
  guess; license and keywords passed through. No URL normalizer, no GitHub-specific rewrite.
• Normalization stamps the result beside model.metadata; each of the three planners fills only
  the fields its host schema supports and only where the host block omits them, then runs its
  existing validator over the merged document, so an invalid value still fails through the host's
  own pinned schema with its own message.
• Precedence, in order: host block value, then an explicit shared override on the existing
  plugin surface, then package.json. A per-host null keeps deliberate absence expressible so
  one host can ship no homepage while another does.
• Provenance: a planner that consumed a shared value adds package.json to its sourceInputs,
  so editing package metadata invalidates exactly the outputs that read it and the existing
  rebuild path notices.
• Proof, per the acceptance list: a composite fixture declaring the metadata once and asserting
  the emitted portable, Cursor, and Claude documents; target add/remove/reorder leaving effective
  metadata unchanged; override and null cases; a malformed package.json field producing a
  source-linked diagnostic; and an actual in-repo consumer config simplified by deleting the
  repeated values rather than wrapping them.

Not in scope, per the non-goals: no capability registry, no identity inference, no automatic
publication, no runtime package discovery, and no claim that a host is supported because
descriptive metadata can be emitted for it.