Link resolved swaps to dashboard URL in view.py

[eureka0928]

Closes #66

Summary

When a swap completes or times out, the contract removes it from on-chain storage. alw view swap <id> previously dead-ended on a generic "Swap resolved" message.

Per your feedback — keeping allways/ as the chain-state-direct layer with no HTTP calls to deployed services — this PR drops the earlier API-client approach and replaces it with a minimal dashboard URL hint that routes users to the module (allways-ui) that owns resolved swap history.

Changes

• allways/cli/swap_commands/view.py — when get_swap() returns None and the swap ID is below next_swap_id, append the dashboard URL (/swap/{id}) to the existing message
• DEFAULT_DASHBOARD_URL module constant (https://test.all-ways.io) overridable via ALLWAYS_DASHBOARD_URL env var
• No new modules, no new dependencies, no HTTP calls from the CLI

Reverted from previous revision: das_api.py, test_das_api.py, and all indexer-fetch logic.

Example

Before:

$ alw view swap 1
Swap 1 has been resolved (completed or timed out).
Resolved swaps are removed from on-chain storage.

After:

$ alw view swap 1
Swap 1 has been resolved (completed or timed out).
Resolved swaps are removed from on-chain storage. View history at: https://test.all-ways.io/swap/1

Test plan

• Manual: alw view swap <resolved_id> prints the dashboard URL
• Manual: alw view swap <active_id> still shows full on-chain details
• Manual: ALLWAYS_DASHBOARD_URL=https://my.host alw view swap <resolved_id> uses the override

[eureka0928]

Hi @LandynDev I put the new PR based on your comments from closed one
Thank you for your time
Let me know if there is any feedback

[LandynDev]

hey, the gap you're solving is real bc view.py still dead-ends on resolved swaps. We can't access the chain efficiently for this data and I'm not sure if I want to introduce the api as a dependency to the CLI just for this. At least not yet, just want to keep things simple right this moment

I thought about this more and here's what I think:
As I mentioned above, the allways/ repo is deliberately the chain-state-direct layer, no module here HTTP-calls a deployed service, and the repo split (das-allways + allways-ui) exists so resolved-swap history has an owner that isn't the CLI.

If you want to close this UX gap in a shape we can land, the smaller move is a ~5-line tweak to view.py that points users at the dashboard URL for the swap id they asked about. Just for V1, for now. They still get the details, we just route them to the module that owns the data instead of proxying it.

I led you wrong direction here in the last PR saying API good route, can we do this instead?

[eureka0928]

Thanks for the clear direction — makes sense. Reverted the API-client approach entirely and replaced it with the ~5-line dashboard URL hint as suggested. No HTTP calls from the CLI, no new modules. ALLWAYS_DASHBOARD_URL env var for override. Ready for another look.