Add integration test: upgrade proposal approval/execution flow

[christabel888]

Context: Hardening pass before the analytics pivot leans on these contracts more heavily for indexing.

Where:

• upgrade/src/test.rs -- upgrade has no test file yet -- this issue includes creating upgrade/src/test.rs

What to do:

• Add test coverage for the full propose_upgrade -> approve_upgrade flow in upgrade/src/lib.rs's UpgradeManager.
• Follow the existing test conventions used elsewhere in the workspace (e.g. escrow/src/test.rs, governance/src/test.rs) for env/contract setup boilerplate.

Suggested approach:

1. Read upgrade/src/lib.rs end to end first -- write down every state transition and every Result::Err path before writing a single test, so you're testing behavior you've actually verified exists, not behavior you assume exists.
2. Cover the happy path first, then the specific edge case named in this issue, then at least one "should fail" case (wrong caller, wrong state, etc.).
3. Use Soroban's test Env with Env::default() and mock auths (env.mock_all_auths() or targeted auth mocking) matching the pattern already used in sibling test files.
4. Since upgrade has no test file yet, set up upgrade/src/test.rs from scratch -- copy the env/contract-registration boilerplate from a sibling crate's test file (e.g. escrow/src/test.rs) rather than reinventing it, and add mod test; to upgrade/src/lib.rs.

Watch out for:

• Soroban contract tests can pass for the wrong reason if you mock all auths globally -- for anything auth-sensitive (which most of these contracts are), mock only the specific caller and verify unauthorized callers are actually rejected.
• Don't test implementation details (exact storage key names) -- test observable behavior (return values, events, subsequent calls succeeding/failing).
• If this crate is also getting event changes from stellar_insights: document submit_snapshot event schema for Soroban Dashboard ingestion #1-upgrade: add upgrade-approved/executed event emission if missing #20's batch, coordinate branch order so you're not writing tests against code that's about to change underneath you.

Definition of done:

• New test(s) added covering the scenario above
• cargo test -p upgrade passes
• Test also runs under the workspace-wide cargo test