docs: Move versioning guidance out of the readme

[nfebe]

Keep version selection and compatibility guidance in the documentation using docs-kit.

[sourceant-local]

Code Review Summary

This pull request successfully moves versioning guidance from the README.md to a dedicated docs/versioning.md file, improving the overall documentation structure. A new GitHub Actions workflow is introduced to validate the documentation using docs-kit, and docs.json is added to configure the documentation build.

🚀 Key Improvements

• Improved documentation structure by moving versioning guidance out of README.md into docs/versioning.md.
• Introduction of docs.json for structured documentation configuration.

💡 Minor Suggestions

• Pin the validate-docs GitHub Action to a specific commit SHA or release tag for better stability and security.
• Clarify the version dependency statement in docs/versioning.md to be more general or specific about its context.
• Consider using generic version placeholders in code examples within docs/versioning.md to prevent quick obsolescence.

[sourceant-local]

Review complete. See the overview comment for a summary.

[sourceant-local]

For stability and security, it's a best practice to pin GitHub Actions to a specific commit SHA or a release tag rather than a floating branch like main. This ensures that your workflow doesn't unexpectedly break or introduce vulnerabilities if the main branch of docs-kit changes.

Suggested change

	- uses: whilesmart/docs-kit/.github/actions/validate-docs@main
	- uses: whilesmart/docs-kit/.github/actions/validate-docs@<COMMIT_SHA_OR_TAG>

[sourceant-local]

Using generic placeholders like X.Y.Z or MAJOR.MINOR.PATCH in documentation examples helps prevent them from becoming outdated quickly and clearly indicates that users should substitute their desired versions. Specific beta versions can be used to show a real-world example, but a more generic approach is often better for sustained relevance.

Suggested change

	```bash
	```bash
	sourceant setup --agent-version <AGENT_VERSION> --core-version <CORE_VERSION>

[sourceant-local]

The statement "CLI 1.0.0-beta.3 needs agent 1.0.0-beta.3 for sourceant stop" could be clarified. If this is a specific compatibility note for these beta versions, it should be stated explicitly. If it represents a general pattern of CLI-agent interaction for stop functionality, it might be better phrased to reflect that general rule, perhaps using placeholders or a more abstract description of the dependency.

Suggested change

	CLI `1.0.0-beta.3` needs agent `1.0.0-beta.3` for `sourceant stop`. The agent defines core compatibility.
	CLI `1.0.0-beta.3` specifically requires agent `1.0.0-beta.3` for `sourceant stop` functionality due to new features/changes. The agent version defines core compatibility.