Move LabRecorder into the monorepo as a component #9

Part of the centralized-monorepo plan: the whole secure stack lives in sccn/secureLSL.

Scope

Bring the security-enabled LabRecorder in as a component (e.g. apps/LabRecorder/).

Current state: neuromechanist/Secure-LabRecorder, branch feature/security-status.

Measured diff vs upstream: 257 insertions / 28 deletions across 6 files, zero references to sodium/ChaCha/Ed25519.

Adds security-status display for encrypted streams, version API info in the About dialog, and security-mismatch detection with informative error dialogs.

License handling (important)

The fork contains commits b4fe41e "Update license to proprietary" and f91e57f "Add proprietary license section to README", which replaced upstream LabRecorder's own license. That is the same pattern being corrected for liblsl/ in #6 / #7, and it should not carry over into the monorepo.

• Restore and preserve upstream LabRecorder's LICENSE in the component directory
• Scope the proprietary notice to the added security code and the integrated work
• Add an entry to THIRD-PARTY-NOTICES.md

Tasks

• Vendor the component with upstream license preserved
• Update docs/integration/labrecorder.md: it currently documents only the drop-in library-replacement path and points at upstream; it needs to cover the in-repo security-aware build
• Add to mkdocs nav if the page moves
• Record the upstream commit the component is based on
• Decide build integration: whether the app builds as part of the top-level CMake or stays independent

Consideration

The security changes are ~250 lines against a substantial C++ application. Vendoring the full tree means carrying a permanent rebase obligation against upstream LabRecorder. Worth confirming that full-tree vendoring is preferred over carrying the patch set, given the monorepo decision.