feat(auth): bootstrap login token from credentials and 2FA during init #138

Motivation

For a new user, copying a personal login token from the ChurchTools web UI is unnecessary friction. ChurchTools supports logging in with username/email and password, completing TOTP when required, and then retrieving the persistent personal login token through the API.

ct init should offer this guided flow while retaining the existing-token path for experienced users.

Proposed interactive flow

After collecting the ChurchTools host and environment:

How do you want to authenticate?
  1. Username and password
  2. Existing login token
  3. Skip login
Choice [1]:

Username and password

1. Ask for username/email.
2. Ask for the password with input hidden.
3. POST /api/login and retain the returned session cookie.
4. If ChurchTools responds with status: "totp", ask for the six-digit code with input hidden and call POST /api/login/totp with code and personId using the same session.
5. Fetch the personal login token through GET /api/persons/{personId}/logintoken.
6. Verify/store only the host and login token.

Existing login token

1. Ask for the token with input hidden.
2. Verify it against the selected host.
3. Store host and token through the existing credential-store path.

Skip login

Create the scaffold only and print an actionable command for logging in later.

Security requirements

• Never persist username, password, or TOTP code.
• Never print or log password, TOTP code, or login token.
• Do not accept passwords through command-line flags, where they can enter shell history or process listings.
• Store only the long-lived login token and its bound host.
• Keep the direct login-token path available.
• On platforms without supported secure credential storage, do not collect credentials merely to discard them; retain the environment-variable guidance until a secure platform store exists.
• Authentication errors must not include secret request bodies.

ChurchTools API

The official API documents these endpoints:

• POST /api/login with username and password
• POST /api/login/totp with code and personId
• GET /api/persons/{personId}/logintoken

The login and TOTP requests must share the session cookie.

Acceptance criteria

• ct init presents the three authentication choices in an interactive terminal.
• Username/password login works without 2FA.
• The TOTP challenge is detected and completed when required.
• Existing login tokens remain supported.
• Password, TOTP, and token prompts do not echo their input.
• Only host and login token reach persistent storage.
• Empty/skip choices leave a valid initialized repository and explain the next step.
• Non-interactive initialization never prompts and does not introduce password flags.
• Tests cover success, TOTP, invalid credentials/codes, skip, secret redaction, and platform-specific storage behavior.

Related to #131.