MAX_REQS hard cap (1024) silently truncates requirements past the limit with no error

[SoundMatt]

Summary

c-FuSa appears to have a hardcoded requirements-count limit (`MAX_REQS = 1024`, found via review of the tool's requirement-loading code) that silently truncates/ignores any `.fusa-reqs.json` entries past the 1024th, with no warning or error emitted by `cfusa check`/`cfusa trace`/etc.

Impact

Downstream consumer `SoundMatt/c-RCP` just grew its requirements catalog from 817 to 975 entries (a legitimate TC18 spec-completeness pass) and is now only 49 entries away from silently hitting this cap. Once crossed, any further added requirements would not be loaded, tracked, or gated by any cfusa command -- with no diagnostic telling the project this happened. For a safety-certification tool, a silent truncation like this is a serious integrity risk: a reviewer trusting "cfusa trace: N/N traced" has no way to know N was capped rather than complete.

Suggested fix

At minimum, either:

1. Make the limit dynamic (no hardcoded cap), or
2. If a cap is intentional for some resource-bound reason, emit a hard error (not silence) when `.fusa-reqs.json` contains more entries than the cap supports, so a project finds out immediately rather than after certification evidence has already been silently incomplete for some time.

Found via this session's requirements-corpus completeness audit of c-RCP -- happy to provide more detail (exact source location, etc.) if useful, I don't have the exact file:line handy from this side but a grep for `MAX_REQS` in the tool's requirement-loading path should find it quickly.