Restore API contract consistency across backend, UI, tests, and documentation

[Tinna23]

Problem

The public API contract has significant divergence between:

• actual backend handlers
• docs/API.md
• README endpoint documentation
• UI API calls
• TypeScript types
• integration tests

There are also compile errors that currently prevent the repository from building.

Scope

First, ensure the repository can compile by fixing the existing blocking errors (Phase 0):

• packages/core/src/api/fees.rs missing closing }
• incorrect .route() registration in main.rs

Then:

• Rewrite docs/API.md to reflect the actual final implementation.
• Update the README endpoint table and architecture description.
• Remove/fix the UI client's /fees/latest call because the route does not exist.
• Remove or correct RecommendRequest.confidence if there is no backend support for it.
• Add integration coverage for:
  • /fees/account/:id
  • /fees/transaction/:hash
  • complete /alerts/config CRUD lifecycle.
• Coordinate the final /fees/recommend contract with Fix analytics, recommendation, and alert correctness #551 before documenting it.
• Remove fictional/fabricated API fields, query parameters, and metrics from the documentation.

Acceptance criteria

The following all pass:

cargo build --release
cargo test --all
cargo clippy --all-targets -- -D warnings

Additionally:

• Every registered production route is accurately documented.
• No documented fictional route remains.
• UI API calls correspond to real backend routes.
• TypeScript API types correspond to actual backend responses/requests.
• Integration tests cover the previously untested account/transaction lookup routes.
• Full alert configuration CRUD is integration-tested.
• Recommendation documentation reflects the final implementation from Fix analytics, recommendation, and alert correctness #551.

Dependencies

The compile fix (Phase 0) can happen immediately.

The final API/documentation work should happen after #550 and #551, because those issues change the underlying behavior that the API documentation must describe.

Non-goals

Do not:

• introduce API versioning
• add unrelated endpoints
• add new product features
• redesign the API beyond resolving the verified inconsistencies
• modify devkit documentation unnecessarily

[Degentle12]

Please can I fix this issue

[northersubair]

can i work on this?

[grantfox-oss]

🦊 GrantFox — @northersubair has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #552)
2. Your PR will be reviewed by the StellarCommons maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@northersubair's PR #559 was approved and merged by @Tinna23.

🏆 @northersubair: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (955 total points). Track your full progress on GrantFox.

👏 Great work, @northersubair! Keep contributing to StellarCommons.