[Bug] tokenizer.decode() infers incorrect true_length compared to decode_with_cfg_fn, causing shape mismatch in example script

[young55775]

Hi, thanks for the amazing work on APT!

I encountered a shape mismatch error while running the provided example script for computing reconstruction RMSD. When encoding a sequence and truncating the tokens to max_toks (128), tokenizer.decode() reconstructs a coordinate tensor of shape (1, 128, 3) instead of the original sequence length (e.g., 256 for a typical PDB), which causes kabsch_rmsd to fail.

To Reproduce:
Following the reconstruction example:

# Assuming x_BLD shape is (1, 256, 3)
_, tok_BLD, idx_BL = tokenizer.encode(x_BLD)
idx_BL = idx_BL[:, :max_toks]  # Truncated to 128

# This returns recon with shape (1, 128, 3)
recon = tokenizer.decode(idx_BL) 

# Raises Error: Expected P and Q with same shape
rmsd = kabsch_rmsd(recon.cpu(), x_BLD.cpu()) * 10

Root Cause Analysis:
I dug into apt.models.dae and found an inconsistency in how true_length is handled when it is None.

In decode_with_cfg_fn(), the length is correctly predicted using size_proj:

if true_length is None:
    length_readout = self.size_proj(c_BLD[:, :4, :].view(c_BLD.size(0), -1)).argmax(-1)
    # ... calculates true_length

However, in the standard decode() function, it just defaults to the sequence length of the codes (idx_BL), which is already truncated to 128:

def decode(self, idx_BL, true_length=None, ...):
    # ...
    if true_length is None:
        true_length = c_BLD.size(1) # <--- Here, it becomes 128 instead of original L