feat: add session transfer commands

[zcutech]

Summary

• add cac env sessions commands to list, copy, and move Claude Code session history across environments
• support project-level and single-session transfers with overwrite protection
• install a cac-session-transfer Claude Code skill for newly created environments
• document session migration in English and Chinese command references
• fix timer handling on platforms where date +%s%N is unsupported

Verification

• bash build.sh
• bash -n cac
• bash -n src/cmd_env.sh
• bash -n src/templates.sh
• bash -n src/utils.sh
• verified session list/copy/move behavior with a temporary HOME

[nmhjklnm]

I found one blocking issue, plus this branch now needs a rebase on current master.

Blocking issue:

• src/cmd_env.sh symlinks skills/ by default in --clone mode, and then src/templates.sh:_write_session_transfer_skill() immediately returns when config_dir/skills is a symlink.
• That means cloned environments created with the default symlink mode do not get the cac-session-transfer skill at all.
• But the docs currently state that new environments include that skill (docs/commands/env.mdx, docs/zh/commands/env.mdx).

So right now the implementation and the documented behavior disagree: fresh non-cloned envs get the skill, default --clone envs do not.

Please either:

1. make cloned envs also receive the skill in a way that does not mutate the shared source skills directory, or
2. narrow the docs/help text so it only promises the skill where it is actually installed.

Also, this PR is currently CONFLICTING with the latest master, so it needs a rebase before it can be merged.

[nmhjklnm]

One softer product concern to think through before this lands:

I do not have hard evidence that raw session_id is treated upstream as a fingerprint, so please treat this as a hypothesis rather than a proven issue.

That said, session data itself is likely sensitive / highly linkable:

• stable session_ids are preserved
• full transcript continuity is preserved
• project directory names encode local path structure
• sidecar / subagent artifacts are preserved too

So even if device identity is regenerated correctly, copying raw session files between environments may still carry a lot of continuity across those environments.

I think the key question for this feature is not just command ergonomics, but whether CAC wants to treat raw session transfer as part of its isolation model, or as an explicit “you are carrying context across boundaries” escape hatch.

Not saying this PR is wrong, only that session sensitivity probably needs to be part of the product decision here.

[nmhjklnm]

Related product stance from my side: even if we do not treat this as a proven fingerprinting issue yet, I would still be cautious about encouraging reuse of old raw sessions across isolated environments.

In other words, my default recommendation would be:

• new environment -> new session
• if context needs to be carried over, prefer a more explicit / reduced form rather than reusing the original session files verbatim

So for me the core concern here is session sensitivity and cross-environment continuity, not just whether session_id alone is definitely used as a fingerprint.