Document project purpose, scope, terminology, and repository map

[DenWin]

Parent: #24.

Audience

New users and contributors who need to understand what ConvertX is before studying implementation details.

Deliverables

• Rewrite/structure README with:
  • purpose and supported use cases
  • explicit non-goals and security assumptions
  • five-minute quick start
  • supported deployment paths
  • authentication modes
  • links to authoritative configuration, architecture, operations, API, and contributing docs
• Add a domain glossary for:
  • user and anonymous user
  • job
  • source file and output file
  • conversion target
  • converter implementation
  • converter capability
  • batch defaults and per-file overrides
  • history, result, and cleanup
• Add a repository map explaining src/pages, src/converters, helpers, public browser code, tests, and deployment files.
• Record supported platforms and architectures without claiming unverified support.
• Clearly identify fork-specific behavior and upstream provenance.

Validation

• Commands are executed from a clean checkout.
• Links are checked.
• Terminology is reused by architecture docs, issues, tests, and UI copy.
• Avoid duplicating configuration tables maintained elsewhere.

Acceptance criteria

• A new reader can identify purpose, constraints, and the correct next document in under five minutes.
• Every core domain term has one stable definition.
• Repository areas have described responsibilities.
• Claims are linked to tests, implementation, or an explicit support policy.