docs(memory): add memory stores section on community page

[opieter-aws]

Description

MemoryStore is a new first-class SDK concept, but the community catalog had no category for it. New community stores that implement the MemoryStore interface had nowhere accurate to go.

This adds a dedicated Memory Stores community category so those packages have a correct, discoverable home, following the same end-to-end pattern every other community category already uses.

A category is defined in six coordinated places, all updated here so the section renders and stays in sync:

• New memory-store value in the integrationType enum, added at the same position in both content.config.ts (Zod schema) and integration-content.ts (the IntegrationType union) per the cross-file sync convention.
• New community/memory-stores/overview.mdx landing page. It intentionally carries no community/integrationType frontmatter: it is a concept/landing page, not a catalog entry, and it gives the nav group a content leaf so the group isn't dropped at build time.
• New Memory Stores nav group under Community in navigation.yml.
• New ## Memory stores catalog section (plus the communityMemoryStores query) in community-packages.mdx.
• Contributor guide (get-featured.mdx) updated: the category list, the directory table, and the allowed integrationType values. The pre-existing Session Managers entry, which read "custom session/memory implementations," is retightened to "custom storage backends for conversation history" so the two categories no longer look overlapping.

The catalog table renders empty (headers only) until the first package is added and fills in automatically as contributors ship stores. Seeding an actual store page is left as a follow-up.

Related Issues

Related: #3082

Documentation PR

This PR is the documentation change. All edits are under site/.

Type of Change

Documentation update

Testing

Ran the site build locally (npm run build): 823 pages built, and the broken-link checker reported no broken links across all 822 HTML pages, which validates every relative link added here and the #memory-stores catalog anchor. Confirmed the new page builds at /docs/community/memory-stores/overview/, the Memory Stores group appears in the Community sidebar, and the catalog page exposes the id="memory-stores" section. astro sync confirmed the schema accepts the new memory-store enum value.

Checklist

• I have read the CONTRIBUTING document
• I have reviewed and understand every line of code in this PR, including any generated by AI tools, and I can explain why it works
• My change is focused and reasonably small; I have split unrelated work into separate PRs
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Documentation Preview Ready

Your documentation preview has been successfully deployed!

Changed pages:

• community/community-packages
• community/get-featured
• community/memory-stores/overview

Updated at: 2026-07-08T21:11:07.760Z

[github-actions]

Assessment: Comment (approve-worthy after minor doc fixes)

Clean, well-scoped docs change that wires up the new Memory Stores community category consistently across all six surfaces. I verified every internal link resolves (including the #custom-stores and #memory-stores anchors), the integrationType enum stays in sync between content.config.ts and integration-content.ts, and the existing test suite isn't broken (known-routes.json is append-only, the sidebar test uses toContain, and sitemap-coverage is gated behind VERIFY_LIVE_SITEMAP).

Review themes

• Contributor guidance accuracy: the directory-table example and the integrationType field-table row in get-featured.mdx are slightly off/incomplete — see inline notes.
• Empty-state UX: the catalog section publishes as a headers-only table until the first store lands; worth deciding intentional vs. gated.
• Intentional design choices (frontmatter-less landing page, session-manager description retighten, cross-file enum sync) are sound and clearly documented in the PR description.

Nicely done keeping the change surgical and following the established end-to-end category pattern.

[github-actions]

Re-review after Address comments — Assessment: Approve ✅

Thanks for the quick turnaround. Verified both get-featured.mdx fixes on the latest commit:

• Directory-table example now reads my-store.mdx, matching the per-package convention (my-plugin.mdx).
• The integrationType field-table row now lists agent-extension, so it's back in sync with both the schema enum and the prose at line 84.

The empty-catalog-table thread is an accepted intentional choice — it's documented in the PR description and the section fills in automatically once the first store ships, so no change needed there.

No regressions and the change stays scoped to the six coordinated site/ files. LGTM.