Bug 42764: Fix false positives caused by POD letter-code formatting

Two patterns in the codebase produce spurious codespell hits because
codespell tokenises word fragments out of formatted letter codes:

- B<P>rovider in C4/Auth_with_shibboleth.pm produces 'rovider'
- T(ransit), W(aiting), F(inished), P(rocessing) in C4/Reserves.pm
  produce 'ransit', 'aiting', 'inished', 'rocessing'

For the shibboleth POD line the bold-letter markup cannot be simplified
without losing the formatting intent, so a per-line # codespell:ignore
comment is the right suppression.

For the Reserves.pm status table the fix is made at source: the notation
is changed from X(word) to X (Word) so codespell sees the full English
word and no fragment is produced.

Because the per-line comment on the shibboleth line now suppresses
'rovider' directly, the global .codespell-ignore entry for that fragment
is removed as redundant.

Test plan:
1. Apply patch
2. prove xt/author/codespell.t
=> No new codespell failures

Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>

.codespell-ignore

@@ -1,7 +1,6 @@
 ser
 thes
 nam
-rovider
 fo
 isnt
 wither

C4/Auth_with_shibboleth.pm

@@ -365,7 +365,7 @@ Note: The minimum you need here is a <matchpoint> block, containing a valid colu
 
 It should be as simple as that; you should now be able to login via shibboleth in the opac.
 
-If you need more help configuring your B<S>ervice B<P>rovider to authenticate against a chosen B<Id>entity B<P>rovider then it might be worth taking a look at the community wiki L<page|https://wiki.koha-community.org/wiki/Shibboleth_Configuration>
+If you need more help configuring your B<S>ervice B<P>rovider to authenticate against a chosen B<Id>entity B<P>rovider then it might be worth taking a look at the community wiki L<page|https://wiki.koha-community.org/wiki/Shibboleth_Configuration>  # codespell:ignore
 
 =head1 FUNCTIONS
 

C4/Reserves.pm

@@ -110,10 +110,10 @@ This modules provides some functions to deal with reservations.
   - priority >0      : then the reserve is at 1st stage, and not yet affected to any item.
              =0      : then the reserve is being dealt
   - found : NULL         : means the patron requested the 1st available, and we haven't chosen the item
-            T(ransit)    : the reserve is linked to an item but is in transit to the pickup branch
+            T (Transit)    : the reserve is linked to an item but is in transit to the pickup branch
-            W(aiting)    : the reserve is linked to an item, is at the pickup branch, and is waiting on the hold shelf
+            W (Waiting)    : the reserve is linked to an item, is at the pickup branch, and is waiting on the hold shelf
-            F(inished)   : the reserve has been completed, and is done
+            F (Finished)   : the reserve has been completed, and is done
-            P(rocessing) : reserved item has been returned using self-check machine and reserve needs to be confirmed
+            P (Processing) : reserved item has been returned using self-check machine and reserve needs to be confirmed
                            by librarian before notice is send and status changed to waiting.
                            Applicable only if HoldsNeedProcessingSIP system preference is set.
   - itemnumber : empty : the reserve is still unaffected to an item