`PartiallyRefunded` status is fully modeled but no code path can ever produce it

[dinahmaccodes]

Tier: Hard
Description: ShipmentStatus::PartiallyRefunded (types.rs:236-237) has valid-transition rules defined (types.rs:306-311), but resolve_dispute (lib.rs:4869-4970) only implements full release or full refund — never a partial split — so PartiallyRefunded is dead scaffolding for an incomplete feature. It's also missing from purge_status_hashes's cleanup list (storage.rs:1729-1745), a latent storage leak once the status becomes reachable.
Files: contracts/shipment/src/types.rs:236-237, 306-311, contracts/shipment/src/lib.rs:4869-4970, contracts/shipment/src/storage.rs:1729-1745
Tasks:

• Implement a partial-refund resolution path in resolve_dispute that can produce PartiallyRefunded
• Add PartiallyRefunded to purge_status_hashes's cleanup list
  Acceptance Criteria:
• PartiallyRefunded is reachable via a real dispute-resolution path and is correctly purged on archival

[aliyuzuliehat25]

@aliyuzuliehat25 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi, I’d like to work on this issue.

I’ll first trace the shipment dispute state machine, refund/release accounting, and archival cleanup flow across types.rs, lib.rs, and storage.rs before making changes. In particular, I’ll verify the existing transition rules and ensure the new partial-refund path is consistent with the contract’s current authorization and asset-flow invariants.

Proposed approach

• Implement a partial-refund resolution path in resolve_dispute that can deterministically produce ShipmentStatus::PartiallyRefunded.
• Define how the refund/release split is represented and validated using the existing dispute-resolution model.
• Ensure the split cannot exceed the available disputed/escrowed amount and cannot create an inconsistent balance.
• Enforce the appropriate authorization and valid state-transition checks.
• Ensure repeated or invalid resolution attempts cannot cause duplicate refunds or releases.
• Add PartiallyRefunded to purge_status_hashes so all associated status data is cleaned up during archival.
• Document the important state and accounting invariants in the implementation.

Test strategy
I’ll add focused contract tests covering:

• Full refund behavior remaining unchanged.
• Full release behavior remaining unchanged.
• Valid partial-refund resolutions producing PartiallyRefunded.
• Boundary cases such as zero, full amount, and minimum/maximum valid splits.
• Invalid splits exceeding the available amount.
• Unauthorized and invalid-state resolution attempts.
• Repeated resolution attempts and protection against double settlement.
• Correct status transitions.
• PartiallyRefunded status hashes being removed during archival/purge.
• Regression coverage for existing dispute-resolution flows.

Validation
I’ll run the focused shipment contract tests, formatting/lint/build checks, and the complete applicable repository CI suite. I’ll also verify the resulting contract behavior against the relevant resource/gas constraints.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @aliyuzuliehat25 to this issue.