Move LabRecorder into the monorepo as a component

[neuromechanist]

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.

[neuromechanist]

Licensing decision for this move (supersedes the license tasks above).

Components retain their original licensing. If the upstream project is MIT, the component stays MIT in this repository, including the security integration code added to it.

This is defensible on the measurements taken while scoping these issues: the integration in all three cases is interface declarations and status-display logic calling the public library API, with zero references to sodium, ChaCha, or Ed25519. There is no cryptographic implementation in any of them, so nothing in these components requires the proprietary grant.

Concretely, for this component:

• Preserve the upstream LICENSE file in the component directory, unmodified
• Do not carry over the "Update license to proprietary" commits from the fork
• The added integration code is contributed under the upstream project's license
• Add the component to THIRD-PARTY-NOTICES.md

The proprietary Secure LSL license continues to cover the security implementation, the core-library modifications, and the integrated work as a whole.

Encoded in LICENSE under COMPONENT LICENSING POLICY on the branch for #6 (PR #7), which should land before these moves.