Add get_version consistency check across all contracts

[christabel888]

Context: Checked every crate directly: 8 of the 10 contracts expose pub fn get_version(env: Env) -> String. analytics has no version function of any kind. upgrade has a differently shaped pub fn version(env: &Env) -> ContractVersion (returns a struct, takes &Env not Env) as part of its UpgradeManager. There is no shared convention.

Where:

• analytics/src/lib.rs -- add a version function
• upgrade/src/lib.rs -- decide whether UpgradeManager::version should also expose the standard get_version(env: Env) -> String shape, or whether the standard needs to accommodate it
• The other 8 crates -- no code change expected, just confirm they match whatever convention is settled on

What to do:

• Pick one convention (recommend keeping get_version(env: Env) -> String since 8/10 crates already use it) and document it in the workspace root Cargo.toml comments or a new CONTRIBUTING.md (see Update workspace Cargo.toml/CONTRIBUTING notes with analytics-pivot event-schema expectations #50).
• Add the missing function to analytics.
• Reconcile upgrade's version() -- either add a matching get_version wrapper or explicitly document why upgrade is the exception.

Suggested approach:

1. Before changing anything, get agreement (even informally, in the PR description) on which shape wins: the 8-crate get_version(env: Env) -> String convention, or something closer to upgrade's ContractVersion-returning version(env: &Env). Recommend the former since it's already the majority pattern and simpler for callers.
2. Add get_version to analytics/src/lib.rs following the exact signature used in the other 8 crates.
3. For upgrade, either add a get_version wrapper that calls into the existing UpgradeManager::version internally, or document explicitly why upgrade is a deliberate exception (it manages versions for other contracts, which arguably justifies a different shape).
4. Document the decision in CONTRIBUTING.md (Add an event schema versioning policy doc so the backend indexer doesn't break on upgrades #32) so the next new contract in this workspace follows it without a repeat of this inconsistency.

Watch out for:

• This is exactly the kind of "small" change that's easy to get subtly wrong across 10 files -- write a quick test or script that calls get_version (or whatever you land on) across all 10 crates and asserts they all respond, rather than eyeballing each one.
• If any deployed instance of these contracts is live, adding a new public function is still an interface change -- treat it with the same care as the event additions in stellar_insights: document submit_snapshot event schema for Soroban Dashboard ingestion #1-upgrade: add upgrade-approved/executed event emission if missing #20.

Definition of done:

• All 10 crates expose a consistent, documented version-query convention
• analytics no longer lacks a version function
• Convention documented in root Cargo.toml comments or CONTRIBUTING.md