docs: Map capability discovery, tool search, gateways, and context compilation

Summary

Create a neutral, evidence-based landscape page explaining where ContextWeaver's compiler-first architecture fits relative to:

• raw MCP/A2A/OpenAPI/Agent Skills discovery;
• MCP gateways and capability registries;
• provider-side deferred tool loading/search and allowed-tool features;
• agent framework tool registries;
• retrieval over tool descriptions;
• prompt/context compaction and memory systems;
• execution runtimes and orchestration platforms.

The page must reflect the approved boundary: ContextWeaver compiles and progressively exposes capabilities/context; the host executes.

Questions the page must answer

1. What problem does each category solve?
2. Which work happens offline versus runtime?
3. Who owns capability execution, credentials and side effects?
4. When is a provider-native tool-search feature sufficient?
5. When does a gateway help but not replace compilation?
6. When is ContextWeaver complementary rather than competitive?
7. What evidence supports each ContextWeaver claim?

Required positioning

source protocols and framework objects
        ↓
ContextWeaver discovery + normalization + analysis + evaluation + compilation
        ↓
versioned capability bundle
        ↓
phase-aware selection and hydration
        ↓
host runtime executes

ContextWeaver is not positioned as:

• a general API gateway;
• an IAM platform;
• a production orchestrator;
• an observability/control plane for every MCP operation;
• a replacement for provider prompt caching or model-side tool search.

Comparison dimensions

• source/protocol coverage;
• offline reproducibility and drift detection;
• identity/duplicate/ambiguity analysis;
• evaluation before promotion;
• bundle portability and provider independence;
• progressive disclosure and hydration;
• phase-specific context compilation;
• execution ownership;
• resource containment and provenance;
• operational infrastructure required.

Evidence and claims rules

• cite official documentation for external products/protocols;
• distinguish documented capability from inference;
• use dated facts where product behavior changes quickly;
• link ContextWeaver claims to reproducible tests, demos or benchmark artifacts;
• state current routing limitations, not only benefits;
• avoid feature-count marketing tables.

Acceptance criteria

• covers at least one representative source protocol, gateway, provider-native tool-search mechanism, framework runtime and context/memory approach;
• clearly explains complementary combinations;
• matches #758 and #376 boundaries;
• documents when users should not adopt ContextWeaver;
• does not claim execution, IAM or control-plane ownership;
• links from README and architecture/stability documentation after the compiler artifact exists.

Start by reading the README and architecture/stability documentation, then inspect the compiler artifact and the boundaries discussed in #758 and #376. Map the required comparison categories to cited external documentation and reproducible ContextWeaver evidence; done means the landscape page covers the acceptance criteria, states non-goals and adoption limits, and is linked from the requested documentation.