New Questions (03-q)

Environment naming during init

parseLocals находит файлы типа .env.prod, ./docker/.env.local

В конфиге environments имеет структуру:
```
environments:
  production:        # <-- это Env.Name
    path: ".env.prod" # <-- это Env.Path
```
Вопрос: Откуда берётся Name ("production")?
- (a) Интерактивный промпт для каждого найденного файла
- (b) Автоматически из имени файла (.env.prod → prod)
- (c) Используем путь к файлу как Name (.env.prod → .env.prod)
answer (c)

При merge трёх версий, где переменная имеет разные значения:
```
VARIABLE: DATABASE_URL
[1] version 1706000001: postgres://v1
[2] version 1706000002: postgres://v2  
[3] version 1706000003: postgres://v3
Select (1/2/3):
```
Это правильное поведение? Или merge должен быть только для двух версий за раз? answer: правильное

api_url в конфиге проекта:
- Разные проекты могут иметь разные api_url?
- Или api_url должен быть глобальным (env var AEVS_API_URL)?
Вопрос: Какой scope у api_url?
- (a) Per-project (в aevs.yaml)
- (b) Global (env var или ~/.config/aevs/config.yaml)
- (c) Both: global default + per-project override
answer (a)

Когда устанавливается имя проекта?

Сценарий:
1. aevs init — промпт "Enter project name"
2. aevs sync — если project_id пустой, создаём проект на сервере
Вопрос: Имя проекта:
- (a) Сохраняется в конфиге во время init, используется при создании на сервере
- (b) Запрашивается только при первом sync
- (c) В конфиге нет имени, только project_id после первого sync
answer: (b), id проекта -- это uuid его можно сгенерировать на клиенте

GET /projects возвращает все проекты:
- Все проекты в системе?
- Только проекты доступные этому api_key?
Для MVP: Один api_key = доступ ко всем проектам?

только доступные проекты (для mvp - создай в inmemory хранилище проекты для другого ключа, чтобы на тестах убедиться, что пользователь его не видит)