db_virtual: fix modparam typo (db_max_consec_retrys)

[denys-i-didww]

Summary

db_virtual registers db_max_consec_retrys; the README documents
db_max_consec_retries. This fixes the code rather than the page, following 36a09ee
(dispatcher: Fix modparam typo (ds_probing_threshhold)): the variable is renamed, both
names are registered against it, and the old one is kept so existing configurations keep
working.

This is the db_virtual item offered in #4242 under Not in this PR.

Why the code and not the documentation

• the misspelling is the code's. Two files below the parameter, the same module already
  spells it correctly: dbase.c assigns the value to con_list[i].no_retries, three
  times;
• across the tree retries appears in 75 places and in identifiers such as
  no_ping_retries, max_db_retries, curr_no_retries. retrys appears seven times,
  and all seven are this one identifier;
• the documented spelling is the project's own judgement, not mine. The README said
  retrys from 2009 until e941906 (docs: fix README.md typos, 5 Aug 2026) corrected
  it. That commit was right about the spelling; only the code had not caught up.

What this changes

int db_max_consec_retrys becomes db_max_consec_retries — seven occurrences across
db_virtual.c and dbase.c — and params[] registers both names against it:

/* kept for backwards-compatibility */
{"db_max_consec_retrys",    INT_PARAM, &db_max_consec_retries},
{"db_max_consec_retries",   INT_PARAM, &db_max_consec_retries},

No documentation change is needed: the README already documents the correct name, and
after this it is true.

Reproduced

Built from source and run against the matching binary. A temporary probe in
virtual_mod_init() printed the variable, and the probe was thrown away afterwards:

configuration	value in db_max_consec_retries
no modparam	10 (the default)
db_max_consec_retrys = 42	42
db_max_consec_retries = 7	7
both, 42 then 7	7

The last row is the point: the two names write to one variable, so the later assignment
wins. Before this change the second row fails on the stock 4.0 package with parameter <db_max_consec_retries> not found in module <db_virtual>. Two controls after it:
db_max_consec_retriez and db_max_consec_retry are still refused, so the module gained
exactly the one name and not a loose match.

Compatibility

None broken. A configuration setting db_max_consec_retrys keeps working and keeps
writing the same variable; nothing in the repository sets either name, so no shipped file
or template changes behaviour. This is a functional change, so CI runs on it — no
[skip ci].

---

AI assistance disclosure. This change and its wording were produced with AI
assistance. Every item was checked against the source before submission:

• the registered name and the variable — db_virtual.c:46 and :98;
• the correctly spelled field it feeds — dbase.c:109, :128, :378, declared
  no_retries at dbase.h:97 and left untouched;
• the 75-against-7 count — repository-wide grep over *.c and *.h; after this change
  the old spelling survives in exactly one place, the compatibility line;
• the README's history — git log -S over the full history, which names e941906 and
  the date;
• the precedent, including that it kept the old name and updated only the documentation —
  36a09ee, and its two siblings deb76e3 (2018, cachedb_mongodb) and db6bf91
  (2007, acc), both of which fixed the code without an alias;
• that two entries sharing one pointer is safe here — modparam.c:78-88 resolves a name
  by strcmp and breaks on the first match, so the shared pointer is not consulted, and
  db_virtual's modparam dependency list is empty, so the added entry registers no
  dependency of its own;
• both names, the default, and the two controls were run against a build of this branch
  rather than reasoned about.