transfer(from, to, amount) in eco-token permits self-transfer; transfer_from rejects it — inconsistent security model #84

Why this matters now:
transfer_from explicitly panics with "token: cannot transfer to self" (added in #67). transfer has no such guard. A self-transfer with transfer is a no-op (balance is correctly maintained due to the two-write pattern reading the already-updated value), but the inconsistency is a security model defect: the justification for rejecting self-transfer in transfer_from (allowance drain without token movement) applies equally to transfer (auth signature without value movement). An auditor reviewing the SEP-0041 implementation will flag this inconsistency. It should be fixed before the formal audit.

Problem / What:
In token.rs, transfer does not check if from == to { panic!(...) }. The function correctly handles the double-write (the test test_transfer_to_self passes and the balance is preserved), but a self-transfer burns the caller's require_auth() credential with no economic effect. The fix is a one-line guard matching transfer_from.

Key Challenges:

• The existing test test_transfer_to_self asserts that self-transfer succeeds and leaves the balance unchanged — this test must be updated to assert that it panics after the fix.
• Ensure the error message matches the transfer_from message for consistency: "token: cannot transfer to self".

Acceptance Criteria:

• transfer(from, to, amount) panics with "token: cannot transfer to self" when from == to.
• test_transfer_to_self is rewritten as #[should_panic(expected = "token: cannot transfer to self")].
• A new positive test confirms valid transfers (from != to) still work.
• cargo test -p eco-token passes.

Relevant files/functions:

• contracts/eco-token/src/token.rs — TokenContract::transfer
• contracts/eco-token/src/token.rs — test_transfer_to_self (test update)

Out of scope: TTL, allowance logic, transfer_from (already fixed).