Unify linting, type checking, formatting, and policy validation

[DenWin]

Parent: #31. Coordinate with #16 and build issue #36.

Current evidence

• ESLint and Prettier are active, while biome.json also defines formatter/linter behavior but @biomejs/biome is not declared.
• TypeScript strictness is strong, but noUnusedLocals, noUnusedParameters, and noImplicitReturns are disabled/commented.
• tsconfig.json excludes tests; type coverage for tests depends indirectly on ESLint parser configuration.
• ESLint Tailwind rules are warnings, which may not fail CI.
• Browser JavaScript, workflows, Dockerfile, Compose, JSON/YAML, shell snippets, Markdown links, and documentation examples lack a unified validation policy.
• The repository has experienced CRLF/LF noise and has no explicit .gitattributes policy.
• Coverage can omit unimported production modules while appearing nearly complete.

Decisions required

• Select authoritative tools and remove redundant configuration, or document distinct non-overlapping responsibilities.
• Define which warnings fail CI.
• Define source, test, browser, workflow, Docker, and documentation validation scopes.
• Define generated-file and line-ending policy.

Required validation

• Type-check production and tests explicitly.
• Enable additional strict TypeScript checks incrementally with tracked exceptions.
• Lint browser globals and server code with correct environments.
• Validate ESLint/Prettier or Biome configuration consistency.
• Add actionlint for workflows.
• Add hadolint or an explicitly chosen Dockerfile policy checker.
• Validate Compose and Docker builds.
• Validate JSON/YAML schemas where available.
• Add Markdown/link/example checks for documentation.
• Add secret scanning and prohibited-file/large-artifact checks.
• Add dependency/unused-export checks with an accurate entry-point configuration.
• Add newline/encoding policy through .gitattributes and EditorConfig.
• Ensure coverage assessment includes a production-module inventory rather than only imported files.

Developer experience

Expose stable fix and check commands. CI uses check-only commands and never modifies files. Errors must identify the owning tool and remediation command.

Acceptance criteria

• Every validation concern has one authoritative owner.
• Local validate matches required CI checks.
• Production, tests, browser code, workflows, Docker, configuration, and docs are covered.
• Warnings cannot silently pass where policy considers them failures.
• Line endings and encoding are deterministic across Windows/Linux.
• Temporary exceptions are explicit, owned, and scheduled for removal.