legal: add CLA agreement and cla-bot configuration - #93

Reviewed this today because four external PRs are in flight (#156, #160, #162, #167/#168 from two contributors) and leaving it unexamined has a real cost. CI is 9/9 green and it merges cleanly against main, so nothing mechanical is in the way. I am not merging it, for three specific reasons — two substantive, one that makes the whole thing inert.

1. The bot this configures is not installed, so merging changes nothing. .clabot is configuration for the hosted cla-bot GitHub App. I checked the head commit of every open PR (#168, #167, #166, #163) and there is no CLA check run and no commit status from cla-bot on any of them, and grep -rn 'cla-bot\|clabot' .github/ finds no workflow wiring either. So as it stands this PR adds a config file that nothing reads. The gating this is supposed to provide would still not exist the moment after merge. Either install the App on xerj-org/xerj (and confirm it posts a check on a test PR), or replace the hosted-bot approach with a workflow in .github/workflows/ that does the same job with GITHUB_TOKEN.

2. CLA.md grants licences to a party it never defines. Sections 2 and 3 grant copyright and patent licences to "the Project Owner", and section 1 Definitions defines You, Contribution and Submitted — but not Project Owner. No legal entity is named anywhere in the document. A grant to an undefined grantee is the one defect that would matter most if XERJ is ever relicensed or offered commercially, which is the scenario the document's own header calls out.

3. The contact placeholder is unfilled. Section 7 obliges the signer to notify us of facts that would make their representations inaccurate, then gives the address as **[MAINTAINER CONTACT — fill in]**.

The file carries its own maintainer note saying it has not been reviewed by a lawyer and that two placeholders must be filled before it is authoritative. That note is honest and correct, and I am taking it at its word rather than merging past it. Asking four external contributors to sign an instrument that names no grantee and no contact would be worse than having no CLA — and the .clabot message text ("we need a signed Contributor License Agreement from…") would be making a claim the repository cannot currently back.

To unblock, in order of who has to do it:

• Name the legal entity that is the Project Owner, as a definition in section 1, and fill in the section 7 contact. Both are owner decisions, not something I should guess at.
• Install the cla-bot App (or swap in a workflow) and verify a check actually appears on a test PR.
• Get counsel to confirm the text grants what you need, then delete the maintainer note at the top of CLA.md — while that note is present, the document says of itself that it should not be relied upon.

The Apache ICLA v2.0 adaptation underneath is a sound choice and the "signature is a PR from your own account adding your username to .contributors" mechanism is a good, low-friction design. The structure is right; it is the three blanks and the missing installation that stop it. Worth noting the timing cost too: signatures collected under an instrument that is later materially corrected may need re-collecting, so it is better to fill these in before the first external contributor signs than after.