Fix Nacos skill backend draft and version handling

[saynoword]

Please do not create a Pull Request without creating an issue first.

What is the purpose of the change

Fix Nacos-backed skill sharing so skill registry storage can be configured independently from session/object storage, Nacos draft and review states are handled without duplicate version creation, and evolve can read the right remote skill content across draft, reviewed, and published-version cases.

Brief changelog

• Add sharing.skill_backend so skill assets can use Nacos while sessions and validation data continue using local/OSS/S3 storage.
• Preserve legacy sharing.backend=nacos compatibility while avoiding accidental object-store inference for Nacos-only configs.
• Support both vN and x.x.x Nacos version formats, defaulting new Nacos skills to 0.0.1.
• Inspect Nacos editingVersion, reviewingVersion, and reviewed versions before upload so existing working versions are not bypassed by creating the next version.
• Read Nacos skill content from working versions first, then the configured label, then the largest published/online/released version when no label is present.
• Skip Nacos skills without downloadable published versions during runtime SkillHub pull/sync.

Verifying this change

• Added unit tests for skill backend configuration, Nacos version generation, Nacos working-version handling, and published-version fallback.
• Ran targeted pytest coverage for Nacos skill hub, skill bundle support, working-version push/evolve paths, versioning, and skill backend config.
• Ran ruff checks on the affected modules and tests.
• Ran whitespace validation with git diff --check.

Follow this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.