Gherkin BDD Scenarios for session timeout and re-auth in CLI wrapper around an LLM

You are a seasoned senior engineer specializing in behavior-driven testing. Your work has helped hundreds of product engineers achieve measurable results.

Produce **Gherkin BDD scenarios** for a new feature: **session timeout and re-auth** in a CLI wrapper around an LLM, with step definitions targeting Vitest.

**Feature:** session timeout and re-auth
**Project:** CLI wrapper around an LLM
**Test framework:** Vitest
**Convention:** use zod (or equivalent) for every external input boundary

## Output 1: Feature file
Path suggestion: `features/pdf-export.feature`.

Structure:
```gherkin
Feature: <name>
  As a <role>
  I want <action>
  So that <outcome>

  Background:
    Given <shared setup>

  Scenario: <happy path>
    Given <preconditions>
    When <action>
    Then <observable outcome>
    And <additional assertion>

  Scenario Outline: <parameterized>
    Given ...
    When ...
    Then ...
    Examples:
      | col | col |
      | ... | ... |
```

Required coverage:
- 1 happy path
- 2-3 alternative paths (e.g. existing user vs. new user)
- 3-4 error paths (validation failures, auth failures, rate limits)
- 1 Scenario Outline with 4-8 examples covering edge values
- 1 scenario covering the single most likely regression

Write every step in business language. NO UI details ("click button #submit"). If you find yourself writing a CSS selector, rewrite the step.

## Output 2: Step definition skeleton
For Vitest, produce a step definitions file (e.g. `features/steps/pdf-export.steps.ts` for Cucumber-JS + Vitest, or `tests/bdd/pdf-export_test.py` for pytest-bdd) that:
- Imports the right framework bindings
- Declares stubs for every Given/When/Then in the feature file
- Uses typed parameters
- Shares state via a `World` or fixture -- no module-level mutable state
- Logs the scenario name on failure

Do NOT implement the step bodies -- leave `throw new NotImplementedError("<step>")` (or equivalent) in each. That is the RED state for BDD.

## Output 3: CI wiring note
- Where the feature file lives
- How to run only this feature
- How to fail the build on undefined steps
- How to produce a JUnit XML report for the CI UI

## Output 4: Review checklist for the scenarios
A 10-item checklist to review the feature file before merging:
- Does every scenario have exactly one When?
- Is business language preserved?
- Are examples table values meaningful, not arbitrary?
- etc.

## Hard constraints
- No implementation details in the feature file
- No scenario longer than 7 steps (if longer, split)
- Respect use zod (or equivalent) for every external input boundary
- Output in this order: feature file, step skeleton, CI note, checklist

Provide a ready-to-use template with placeholder markers {{like_this}} that the user can fill in. Include instructions for each placeholder.