lots.transfer() silently no-ops when quantity="ALL" and destination matches source location

[karim-albert]

When calling client.lots.transfer() with quantity="ALL" and a storage_location_id that matches the lot's current location, the SDK returns the unchanged lot with no error or warning. The Albert UI correctly rejects this with "Full Transfer is not allowed for same location", but the SDK gives no indication that nothing happened.

Steps to Reproduce

client.lots.transfer(
    lot_id="LOTA1",
    quantity="ALL",
    storage_location_id="<same location as source lot>",
)
# Returns the lot silently -- no error raised

Expected Behavior

A ValueError is raised with a message matching the UI's behavior:

ValueError: Full Transfer is not allowed for the same storage location. 
Provide a different destination storage_location_id.

Actual Behavior

The method returns the unmodified lot as if the operation succeeded.

Proposed Fix

In src/albert/collections/lots.py, inside the quantity == "ALL" branch of transfer(), add an explicit guard before the patch:

if current_location_id == storage_location_id:
    raise ValueError(
        "Full Transfer is not allowed for the same storage location. "
        "Provide a different destination storage_location_id."
    )

Test to Add

Replace the existing test_transfer_all_same_location_no_op test in tests/collections/test_lots.py with:

def test_transfer_all_same_location_raises(client: Albert, seeded_lot: Lot):
    current_location_id = seeded_lot.storage_location.id
    with pytest.raises(ValueError, match="Full Transfer is not allowed for the same storage location"):
        client.lots.transfer(
            lot_id=seeded_lot.id,
            quantity="ALL",
            storage_location_id=current_location_id,
        )

[prasad-albert]

This is the no-op you asked for in #444. We shipped it in #447 so transfer(quantity="ALL") would not 400 when the lot is already at that storage location.
We cannot keep changing the behavior. Raising a ValueError would be a behavioural change and would break callers who depend on it.
I think we can add a warning and documentation around this though.

[karim-albert]

Warning + documentation is fine with me. The ValueError suggestion was just what Claude gave as a suggestion, but we can ignore that if it would change the functionality too much

[prasad-albert]

Perfect, I can add warning+docs around this