docs(config): fix keyring template so set_password matches lookup

[nicolasbisurgi]

Summary

Documentation-only fix. config/config.ini.template showed a
keyring.set_password command that stored the secret under a
service/account combination RushTI never queries.

Code lookup (src/rushti/tm1_integration.py:93):
keyring.get_password(<instance_name>, <user>)

Old template:
keyring.set_password('TM1py', 'tm1srv01', 'mypassword') — stored under
service 'TM1py', account <instance>. Never matched.

Fixed template:
keyring.set_password('<instance>', '<user>', 'mypassword') — now
matches what the code reads.

Also documents the missing use_keyring=true step; keyring is opt-in
per section and the previous template omitted that.

No runtime change; template comment only.

Test plan

• Copy template to config.ini, add use_keyring=true, run the
  updated keyring.set_password command, launch rushti run ...,
  confirm connection succeeds without the "no password found in
  keyring" warning.
• Run the old command against a fresh keyring, confirm the warning
  still fires (proves the old template was wrong).

🤖 Generated with Claude Code

[MariusWirtz]

Would it be possible to add a run mode where RushTI reads the password from the config.ini file and stores it in the Windows Credential Manager using Keyring?

The main use case is environments where the TM1 Service runs under a dedicated service account. In those cases, the Windows Credential Manager is account-specific, so the password has to be registered manually for that account. Having RushTI perform this step automatically would make the initial setup much simpler and avoid the need for manual intervention.