feat: single prediction sequence name for fasta

[vtnphan]

Pull Request

Summary

SBP-458 — Replaces auto-generated FASTA header IDs (e.g. pro_1) with a required, user-editable sequence name, tags each header with its molecule type (e.g. >seq1|protein), and adds a character-position ruler above the sequence input.

Changes

• Added a required name field per entity row, validated (non-empty, no spaces/underscores, unique) via validateFastaHeader.
• FASTA headers now use the user-entered name and append |type (ligand → smiles); removed the old getFastaSequenceId generator.
• Submission payload entity id now uses the row name instead of entity_N.
• Added a position ruler above the sequence textarea: shows the 1-based residue position above every 10th character and above the final character, with a wider gap after each group of 10 for readability. Implemented as a decorative overlay layer (getSequenceCells) behind a transparent, fully-editable textarea so native typing/selection/paste/scroll behaviour is preserved; scroll position is kept in sync via syncSequenceOverlayScroll.
• Updated specs to cover the new field, validation, and header format.
• Breaking: consumers relying on old pro_1/entity_N IDs need to account for user-supplied names and the |type suffix.

How to Test

1. Open Single Prediction — each entity row now shows a > name input; blank/spaced/underscored or duplicate names show a validation error.
2. Set copy number > 1 and check generated FASTA headers look like >name_1|protein.
3. Switch molecule type to Ligand (SMILES/CCD) and confirm the tag becomes |smiles / |ccd.
4. Open the CCD dropdown and confirm it's no longer clipped.
5. Type/paste a sequence longer than 10 characters and confirm position numbers appear above every 10th character and the last character, that wrapped lines keep labels attached to the correct row, and that typing/selecting/scrolling in the field still behaves like a normal textarea.
6. npm test and npm run prettier:check pass.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have added tests that prove my fix is effective or that my feature works
• I have added or updated documentation where necessary
• I have run linting and unit tests locally
• The code follows the project's style guidelines

[minh-biocommons]

looks good