[Code scan] Pass type_map to dpdata when preparing FP tasks

This issue is a result of a Codex global code scan of `deepmodeling/fpop` at commit `b05b337590c31a5237b2dcbd9c0833b841c08cd4`.

Relevant code:
https://github.com/deepmodeling/fpop/blob/b05b337590c31a5237b2dcbd9c0833b841c08cd4/fpop/prep_fp.py#L121-L141
https://github.com/deepmodeling/fpop/blob/b05b337590c31a5237b2dcbd9c0833b841c08cd4/fpop/vasp.py#L90-L98

Problem:
`PrepFp.execute()` reads `type_map` from `op_in`, but the value is never passed to `dpdata.System(...)`. For `deepmd/npy` inputs that contain `type.raw` but do not contain `type_map.raw`, dpdata loads atom names as synthetic names such as `Type_0` and `Type_1`.

That breaks downstream preparation. For example, VASP POTCAR generation indexes the pseudopotential map by `atom_names`, so `VaspInputs.make_potcar()` can raise `KeyError: 'Type_0'` even though the workflow input provided `type_map=["H", "O"]`.

Minimal reproduction:
```python
s1 = dpdata.System(root, fmt="deepmd/npy", labeled=False)
print(s1["atom_names"])
# ['Type_0', 'Type_1']

s2 = dpdata.System(root, fmt="deepmd/npy", labeled=False, type_map=["H", "O"])
print(s2["atom_names"])
# ['H', 'O']
```

Expected behavior:
`PrepFp.execute()` should preserve the workflow-provided `type_map` when loading configurations, or otherwise map dpdata's synthetic names before calling backend-specific `prep_task()` implementations.

Start in fpop/prep_fp.py at the configuration loading code around lines 121-141 and trace how the workflow's type_map is read. Compare that call with dpdata.System's type_map behavior, then inspect fpop/vasp.py around lines 90-98 where atom_names index the pseudopotential map. Done means deepmd/npy inputs with type.raw but no type_map.raw retain the provided names and no longer produce the Type_0 KeyError during VASP preparation.

Written by the indexing model from the issue text.