Proposal: portable bundle descriptors for pre-load discovery in multi-bundle agent runtimes

## Summary

OKF supports progressive disclosure *within* a bundle, but not *across a set of bundles*.

When an agent runtime mounts multiple OKF bundles, the first-hop context often contains only opaque bundle identifiers or paths. The agent cannot reliably decide which bundle to search without eagerly opening every root `index.md` or scanning concept metadata.

This issue proposes a small, portable **bundle descriptor** based on optional bundle-level `title` and `description`, plus consumer guidance to expose that descriptor before loading the root index body or any concepts.

## Current gap

The current v0.2 specification provides:

- [§8](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md#8-index-files): `index.md` supports progressive disclosure of the contents *inside* a directory.
- [§4.1](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md#41-frontmatter): `title` and `description` are recommended for concept documents.
- [§12](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md#12-versioning): the bundle-root `index.md` may carry `okf_version`, while §8 otherwise says index files contain no frontmatter.

As a result, a catalog can enumerate bundle references, but there is no standard machine-readable answer to:

> What is this bundle about, and when should an agent consult it?

Concept-level descriptions arrive too late: the consumer must first choose and open a bundle to discover them.

## Proposed minimal contract

Allow a bundle to publish a compact descriptor, for example in root `index.md` frontmatter:

```yaml
---
okf_version: "0.2"
title: Cloud cost optimization
description: Guidance for analyzing spend, budgets, and optimization opportunities.
---
```

A catalog or runtime could expose a lightweight discovery record such as:

```json
{
"bundle_ref": "",
"title": "Cloud cost optimization",
"description": "Guidance for analyzing spend, budgets, and optimization opportunities."
}
```

The identifier and revision mechanism remain consumer-defined. The interoperable OKF part is the meaning of `title` and `description`.

## Progressive consumption flow

1. **Discover bundles:** expose only compact bundle descriptors.
2. **Select scope:** choose the likely relevant bundle or bundles.
3. **Navigate:** read the selected root `index.md` for directory-level disclosure.
4. **Retrieve:** search or traverse concept links.
5. **Hydrate:** load full concept documents only when needed.

This mirrors the useful property of an Agent Skill description: the agent can decide whether to load something before paying the cost of loading it.

## Relationship to existing discussions

- #96 proposes orientation hints such as `purpose`, `task`, and `audience`. PR #189 currently applies those hints to concept frontmatter. The [multi-bundle comment](https://github.com/GoogleCloudPlatform/knowledge-catalog/issues/96#issuecomment-5312950092) identifies the same motivating use case.
- #212 asks whether root-index frontmatter may contain producer keys.
- #214 asks for a general home for collection-scoped metadata.

Those discussions address field vocabulary or storage location. This issue focuses on the missing **discovery contract and consumption order**: bundle metadata must be available before concept loading to provide actual progressive disclosure.

## Compatibility and scope

- The fields can remain optional and backward-compatible.
- Existing bundles without a descriptor remain consumable; a consumer may derive a display title or leave the description absent.
- This does not prescribe a query API, storage backend, invocation format, or taxonomy.
- The root-index body and existing concept model remain unchanged.
- If a manifest or sidecar is preferred over root-index frontmatter, the same descriptor semantics and consumption flow still apply.

## Open questions

1. Should bundle-level `title` and `description` live in root `index.md` frontmatter or another reserved bundle metadata location?
2. Should they be optional or recommended for agent-facing bundles?
3. Should §8 include informative consumer guidance that catalogs expose the descriptor before loading index bodies and concepts?

Start with okf/SPEC.md sections 4.1, 8, and 12, then read related issues #96, #212, and #214 and PR #189. Compare the proposed root-index frontmatter and sidecar alternatives, and document a settled descriptor location, field semantics, optionality, and consumer ordering guidance.

Written by the indexing model from the issue text.