Support installing extensions from monorepo / marketplace

### What would you like to be added?

A supported way to install an extension from a repository that contains more than one installable extension. Today `gemini extensions install ` requires `gemini-extension.json` at the repo root, so one repo can only ever be one extension.

Three shapes would solve this, and any one of them unblocks the use case:

1. **Subdirectory install primitive.** Treat a subdirectory as the extension root:

```bash
gemini extensions install https://github.com/org/skills-catalog --subdir extensions/foo
```

This was requested in #25676 and closed without plans. It composes with the existing `--ref` flag for pinning, and `gemini extensions update` would re-fetch the same subdir.

2. **Catalog-aware install.** If the repo root carries a catalog manifest listing extensions and their paths, let the user install by name:

```bash
gemini extensions install https://github.com/org/skills-catalog --name foo
```

The manifest could be a Gemini format, or Gemini could read the `marketplace.json` layout that several other agent CLIs already consume.

3. **Marketplace semantics (the Claude Code / Codex model).** Adopt the catalog model the other two major agent CLIs have converged on: a manifest at the repo root lists extensions and their relative-path sources, the CLI registers the repo as a marketplace, and installs/updates are addressed by name against it:

```bash
gemini extensions marketplace add https://github.com/org/skills-catalog
gemini extensions install foo@skills-catalog
```

Claude Code implements this with `.claude-plugin/marketplace.json` (`/plugin marketplace add org/repo`, then `/plugin install name@marketplace`). Codex implements the same shape with `.agents/plugins/marketplace.json` (repo- or user-scoped catalogs feeding its plugin browser and installs). The two layouts differ only in file location and a few field names — both reduce to a root manifest containing a list of `{name, relative source path}` entries. A Gemini equivalent — or direct support for reading one of those existing manifests — would let a single catalog repo serve every harness unchanged, and gives Gemini a natural home for update semantics (refresh the marketplace, update installed extensions by name).

Option 1 alone is enough to unblock publishers, since a catalog is just tooling layered on top of subdirectory installs. But **option 3 is the preferred shape**: Claude Code and Codex — the two largest players alongside Gemini — have independently converged on marketplace semantics, publishers are already structuring catalog repos to that model, and matching it means Gemini gets the whole ecosystem of existing catalogs rather than a Gemini-only primitive.

### Why is this needed?

Publishers distributing agent skills/plugins across multiple harnesses have converged on a single catalog repo. The `marketplace.json` layout is installable from Claude Code, Codex, Copilot CLI, Devin, and OpenCode. Gemini CLI is the notable harness that cannot install from such a repo, because it only looks for `gemini-extension.json` at the root.

Concrete case: we (O'Reilly Media) are building a curated catalog of expert-authored skills for our customers, published from one repo. Our build pipeline can already emit a valid `gemini-extension.json` per extension in its subdirectory; there is simply no way to point `gemini extensions install` at it.

The only current workaround is one repo per extension. For a curated catalog of N extensions that means N repos to version, permission, and keep in sync, which does not scale and makes Gemini the odd surface out. Forking or vendoring the files loses `gemini extensions update` / `--auto-update`, which is one of the extension system's best properties.

### Additional context

- #25676 requested the subdirectory primitive and was closed citing resourcing; #26032 requested a marketplace/directory and was closed the same way. This is an updated request combining the two from the perspective of a cross-harness publisher, where the gap is now a concrete adoption blocker rather than a nice-to-have.
- The triage bot's effort analysis on #25676 already sketched the implementation surface (extension resolution in `packages/core`, flag propagation from `packages/cli`, subdir metadata in `.gemini-extension-install.json`).
- Related ecosystem context: multi-agent build tools currently work around this by emitting `gemini-extension.json` at the repo root, which only works when a repo contains exactly one extension.

Start by reading extension resolution in packages/core and flag propagation from packages/cli, then inspect the existing .gemini-extension-install.json metadata and the install/update flow. Compare the subdirectory and marketplace proposals against the current root-manifest assumption. Done means a supported design and implementation can install and update one extension from a multi-extension repository.

Written by the indexing model from the issue text.