## Issue description

Saving an edit with async mode sometimes chops of the first character.

Happens when searching entire moderately sized projects and editing many files.
**Examples:** *updating Javascript Versions in HTML files or includes in PHP Files*
See the `How to Recreate` section

#### Things about your system and environment（请在此填写你的系统信息）

| field | value |
|:-------:|:------------------------------------:|
| os | *Windows 10 Pro 21H1* |
| vim | *Vim 8.2 Included patches: 1-12* |
| backend | *ag 2.2.5* |
| locale | *C.UTF-8* |

- vimrc:
```vim
" CtrlSF
" let g:ctrlsf_debug_mode = 1
" Maps -> Ctrl+F . Letter
nmap f CtrlSFPrompt
vmap f CtrlSFVwordPath
vmap F CtrlSFVwordExec
nmap n CtrlSFCwordPath
nmap p CtrlSFPwordPath
nnoremap o :CtrlSFOpen
nnoremap t :CtrlSFToggle
inoremap t :CtrlSFToggle

" Default Regex on
" let g:ctrlsf_regex_pattern = 1
" Don't be hangin
let g:ctrlsf_search_mode = 'async'
```

- Log:
No Logs

### How to Recreate:
* Create an Empty Folder and Run this Shell Script in it (Replicating project size)
* End might need to be tweaked if you've got a super PC, async needs to render results in multiple batches.
* File type doesn't matter, but php/html shows the issue well
```shell
#!/bin/sh

TEXT="\n\n\n\nTest\n\n?>"

START=1
END=55

for (( c=$START; c<=$END; c++ ))
do
echo -e $TEXT > ${c}_tmp.php
done

((END=END+1))

ENDTEXT="\n\n\n\nLast\n\n\n\t

\n\t

---

\n\t\n\n?>"
echo -e $ENDTEXT > ${END}_tmp.php
```
* Search the files in the folder using this: ```CTRLSF Test -filetype php```

* Before continuing, search 5 spaces in the results buffer
* This will show you the underlying issue / reason
* Note: **All** files but the last are the same

* Edit using: ```%s/Test/test/``` + Save&Write
* Re-Search using: ```CTRLSF test -filetype php```
* Higher up results should be missing the first character
* if not: increase END

##### Before Edit
```php

Test

?>
```

##### After Edit
```php

meta charset="utf-8">
html lang="en">
head>
title>test
/head>
>
```
##### **Note:** rerunning the Shell Script resets files to the original (Good for debugging!)

### Reason:
* Due to ```ctrlsf#db#MaxLnum()``` changing mid-search + not updating already rendered matches
* Generates `x` results, with max length 7, rendering with the default 4 spaces.
* Suddenly finds result with max length 19, uses 5 spaces to render it and any result found after.
* On write, uses the max length 19, ignoring 5 spaces for write, which excludes the first char from the results rendered using 4 spaces.

### My Solution:
* I made a fork and fixed it for myself, I kept hitting this issue + breaking prod
* https://github.com/Nealium/ctrlsf.vim/issues/2
* I gave each Paragraph their own Max Line attribute and used that to render+save
* This solution is iffy, as files with two paragraphs could have different tabs, could be confusing (I haven't even noticed it though)
* I pondered adding the Max Line to the File Obj, but that seemed like a lot of work as rendering+saving is built around Paragraphs
* It took me a while to make an issue because I knew I would have to figure out a way to accurately recreate it