docs: hard-wrap pre-existing long prose lines to satisfy doc-linter

scripts/doc-linter.py enforces an 80-character limit outside fenced code
blocks and treats any finding as a failure. Wrap long paragraphs in
files that this PR touched so CI passes:

- docs/configuration/protocols/ospf.md: wrap the WireGuard cost note.
- docs/configuration/protocols/traffic-engineering.md: wrap the IS-IS/
  OSPF note.
- docs/contributing/debugging.md: wrap the Phabricator paragraph, and
  guard the long [bootchart.conf]/[vyatta-cfg] link references at EOF
  with `% stop_vyoslinter`/`% start_vyoslinter`.
- docs/vpp/configuration/ipsec.md: wrap the integration, requirements,
  algorithm, ACL, VTI example, troubleshooting paragraphs.

Pure reformatting; no semantic changes.

https://claude.ai/code/session_01RDpSBDLSWLKMGnyPCaKECB

4 files changed, 81 insertions, 27 deletions

diff --git a/docs/configuration/protocols/ospf.md b/docs/configuration/protocols/ospf.md
index 3e721441..7736f0c9 100644
--- a/docs/configuration/protocols/ospf.md
+++ b/docs/configuration/protocols/ospf.md
@@ -1460,8 +1460,9 @@ set protocols ospfv3 redistribute connected
 show ipv6 ospfv3 redistribute
 ```
 
-Cost calculation wireguard interfaces is unreliable as ospfv3 uses the link speed to calculate the link cost.
-You might therefore want to set the link cost to a fixed value on WireGuard tunnels.
+Cost calculation wireguard interfaces is unreliable as ospfv3 uses the link
+speed to calculate the link cost. You might therefore want to set the link
+cost to a fixed value on WireGuard tunnels.
 
 Example configuration for WireGuard interfaces:
 
diff --git a/docs/configuration/protocols/traffic-engineering.md b/docs/configuration/protocols/traffic-engineering.md
index 27d54af8..fc0841c7 100644
--- a/docs/configuration/protocols/traffic-engineering.md
+++ b/docs/configuration/protocols/traffic-engineering.md
@@ -7,7 +7,8 @@ alternative path.
 
 ## Common link parameters
 
-Traffic Engineering parameters are used for both IS-IS and OSPF (not supported yet).
+Traffic Engineering parameters are used for both IS-IS and OSPF (not supported
+yet).
 
 ```{cfgcmd} set protocols traffic-engineering admin-group \<admin-group-name\> bit-position \<bit-position-value\>
 
diff --git a/docs/contributing/debugging.md b/docs/contributing/debugging.md
index f31fb8f3..07dd80a4 100644
--- a/docs/contributing/debugging.md
+++ b/docs/contributing/debugging.md
@@ -164,8 +164,8 @@ The file `/tmp/foo` contains the migrated configuration.
 ### Configuration Error on System Boot
 
 Running the latest rolling releases sometimes exposes bugs due to edge cases
-missed in design. File these bugs via [Phabricator](https://vyos.dev/), but you can help narrow
-down the issue by following these steps:
+missed in design. File these bugs via [Phabricator](https://vyos.dev/), but
+you can help narrow down the issue by following these steps:
 
 1. Log in to your VyOS system.
 2. Enter configuration mode: `configure`
@@ -200,5 +200,9 @@ To debug priority issues or see script execution order, use the
 `/opt/vyatta/sbin/priority.pl` script, which lists the execution order of
 scripts.
 
+% stop_vyoslinter
+
 [bootchart.conf]: https://github.com/vyos/vyos-build/blob/current/data/live-build-config/includes.chroot/etc/systemd/bootchart.conf
 [vyatta-cfg]: https://github.com/vyos/vyatta-cfg
+
+% start_vyoslinter
diff --git a/docs/vpp/configuration/ipsec.md b/docs/vpp/configuration/ipsec.md
index 8d06f8f6..9dc0fca5 100644
--- a/docs/vpp/configuration/ipsec.md
+++ b/docs/vpp/configuration/ipsec.md
@@ -9,27 +9,39 @@ lastproofread: '2025-09-04'
 
 # VPP IPsec Configuration
 
-VPP Dataplane in VyOS can offload IPSec processing from kernel. This allows to speed-up IPSec traffic handling significantly, when necessary conditions are met.
+VPP Dataplane in VyOS can offload IPSec processing from kernel. This allows
+to speed-up IPSec traffic handling significantly, when necessary conditions
+are met.
 
 :::{note}
-VPP IPsec implementation is not as feature rich as Linux kernel IPsec. It supports only a subset of algorithms and modes.
+VPP IPsec implementation is not as feature rich as Linux kernel IPsec. It
+supports only a subset of algorithms and modes.
 :::
 
 ## Requirements
 
 To make IPSec offloading work, following requirements must be met:
 - VPP dataplane must be configured.
-- VPP {doc}`IPsec settings </vpp/configuration/dataplane/ipsec>` should be configured as needed.
-- IPSec should be configured in the VPN configuration section, see {doc}`/configuration/vpn/ipsec/index`.
-- Both source and destination of the IPSec traffic must be reachable via VPP interfaces, so it can perform both encryption and decryption of the traffic.
+- VPP {doc}`IPsec settings </vpp/configuration/dataplane/ipsec>` should be
+  configured as needed.
+- IPSec should be configured in the VPN configuration section, see
+  {doc}`/configuration/vpn/ipsec/index`.
+- Both source and destination of the IPSec traffic must be reachable via VPP
+  interfaces, so it can perform both encryption and decryption of the traffic.
 
 ## Integration Details
 
-VPP Dataplane offloads IPSec processing from kernel, but does not handle IPSec configuration itself. IPSec configuration management and control-plane operation, like IKE negotiation, is still done by the kernel and other daemons.
+VPP Dataplane offloads IPSec processing from kernel, but does not handle IPSec
+configuration itself. IPSec configuration management and control-plane
+operation, like IKE negotiation, is still done by the kernel and other daemons.
 
-After an IPSec tunnel is configured in the kernel, VPP receives the necessary information via netlink messages and creates a corresponding SAs and policies to be able to offload the traffic.
+After an IPSec tunnel is configured in the kernel, VPP receives the necessary
+information via netlink messages and creates a corresponding SAs and policies
+to be able to offload the traffic.
 
-When VPP is used for offloading IPsec, it creates a virtual interface of a specific type to connect to a peer. The type of the interface can be configured using the `interface-type` parameter in the dataplane settings.
+When VPP is used for offloading IPsec, it creates a virtual interface of a
+specific type to connect to a peer. The type of the interface can be
+configured using the `interface-type` parameter in the dataplane settings.
 
 ## Supported IPsec Modes
 
@@ -40,7 +52,10 @@ VPP supports offloading IPsec connections in the following IPsec modes:
 ## Supported Encryption and Integrity Algorithms
 
 :::{warning}
-Since VPP dataplane is used only to offload IPsec traffic processing, algorithms mentioned below are applicable to ESP profiles in the IPsec configuration. IKE profiles are not affected by these limitations and can use any algorithms supported by the kernel.
+Since VPP dataplane is used only to offload IPsec traffic processing,
+algorithms mentioned below are applicable to ESP profiles in the IPsec
+configuration. IKE profiles are not affected by these limitations and can
+use any algorithms supported by the kernel.
 :::
 
 VPP **supports** only the following **encryption algorithms**:
@@ -77,13 +92,17 @@ VPP **does not** support the following **integrity algorithms**:
 - AES CMAC
 - AES-GMAC
 
-If you have configured ESP profiles with algorithms not supported by VPP and the traffic for such peers flows through VPP interfaces, such traffic will be dropped.
+If you have configured ESP profiles with algorithms not supported by VPP and
+the traffic for such peers flows through VPP interfaces, such traffic will be
+dropped.
 
 ## Configuration Examples
 
 **ACL for VPP IPsec Traffic**
 
-When using VPP for offloading IPsec traffic, you may need to adjust your firewall rules to allow the necessary protocols and ports. Below is an example of how to configure ACLs for VPP IPsec traffic:
+When using VPP for offloading IPsec traffic, you may need to adjust your
+firewall rules to allow the necessary protocols and ports. Below is an
+example of how to configure ACLs for VPP IPsec traffic:
 
 ```none
 set vpp acl ip interface <interface-name> input acl-tag 10 tag-name 'IPSEC'
@@ -104,7 +123,9 @@ set vpp acl ip tag-name IPSEC rule 50 action 'permit'
 set vpp acl ip tag-name IPSEC rule 50 protocol 'esp'
 ```
 
-Pay attention to the order of the rules, as they are processed sequentially. Make sure to place IPsec-related rules before any other rules that might deny traffic to ensure that IPsec traffic is allowed.
+Pay attention to the order of the rules, as they are processed sequentially.
+Make sure to place IPsec-related rules before any other rules that might
+deny traffic to ensure that IPsec traffic is allowed.
 
 **Simple VTI-based IPsec Tunnel**
 
@@ -151,18 +172,24 @@ set vpp settings lcp ignore-kernel-routes
 
 Where:
 - `eth1` is the interface connected to the IPsec peer.
-- `eth2` is the interface connected to the local subnet, where unencrypted traffic is expected.
-- `192.168.100.0/24` is the local subnet that will be accessible through the IPsec tunnel.
-- `192.168.200.0/24` is the remote subnet that will be accessible through the IPsec tunnel.
+- `eth2` is the interface connected to the local subnet, where unencrypted
+  traffic is expected.
+- `192.168.100.0/24` is the local subnet that will be accessible through the
+  IPsec tunnel.
+- `192.168.200.0/24` is the remote subnet that will be accessible through the
+  IPsec tunnel.
 - `vti1` is the VTI interface created by VPP for the IPsec tunnel.
-- `peerA` and `peerB` are the identifiers for the local side and remote peer, respectively.
+- `peerA` and `peerB` are the identifiers for the local side and remote peer,
+  respectively.
 
 :::{note}
 **What is important in this configuration**
 
-VPP uses only remote traffic-selector to determine what traffic should be offloaded to the IPsec tunnel.
+VPP uses only remote traffic-selector to determine what traffic should be
+offloaded to the IPsec tunnel.
 
-Adding additional routes via VTI interface does not affect actual VPP IPsec operation.
+Adding additional routes via VTI interface does not affect actual VPP IPsec
+operation.
 :::
 
 ## Potential Issues and Troubleshooting
@@ -170,19 +197,40 @@ Adding additional routes via VTI interface does not affect actual VPP IPsec oper
 Improper IPsec configuration can lead to various issues, including:
 - **Unidirectional traffic flow or acceleration**
 
-  If kernel has a conflicting route for the remote subnet, such route may take precedence over the policy route created for the IPsec tunnel in VPP. This may lead to unidirectional traffic flow or acceleration only in one direction. This has no security impact because traffic will still be encrypted by the kernel, but it may lead to performance degradation. To avoid this, ensure that no conflicting routes exist in the kernel routing table.
+  If kernel has a conflicting route for the remote subnet, such route may
+  take precedence over the policy route created for the IPsec tunnel in VPP.
+  This may lead to unidirectional traffic flow or acceleration only in one
+  direction. This has no security impact because traffic will still be
+  encrypted by the kernel, but it may lead to performance degradation. To
+  avoid this, ensure that no conflicting routes exist in the kernel routing
+  table.
 
 - **Conflicting with kernel routes**
 
-  If the kernel routes synchronization option is enabled, VPP will install all the routes from kernel. If you have there routes configured via VTI interfaces to the IPsec peer, they will conflict with the policy routes created for the IPsec tunnel in VPP. Consider using policy-based IPSec configuration to avoid this or [disable the kernel routes synchronization](lcp.md#vpp-lcp-configuration).
+  If the kernel routes synchronization option is enabled, VPP will install
+  all the routes from kernel. If you have there routes configured via VTI
+  interfaces to the IPsec peer, they will conflict with the policy routes
+  created for the IPsec tunnel in VPP. Consider using policy-based IPSec
+  configuration to avoid this or
+  [disable the kernel routes synchronization](lcp.md#vpp-lcp-configuration).
 
 - **Unsupported algorithms**
 
-  If you have configured ESP profiles with algorithms not supported by VPP and the traffic for such peers flows through VPP interfaces, such traffic will be dropped. You can check system logs for messages from VPP with `linux-cp/ipsec: Invalid/Unsupported crypto algo` or `linux-cp/ipsec: Invalid/Unsupported integ algo` line to identify such cases.
+  If you have configured ESP profiles with algorithms not supported by VPP
+  and the traffic for such peers flows through VPP interfaces, such traffic
+  will be dropped. You can check system logs for messages from VPP with
+  `linux-cp/ipsec: Invalid/Unsupported crypto algo` or
+  `linux-cp/ipsec: Invalid/Unsupported integ algo` line to identify such
+  cases.
 
 - **Connection is established but no traffic flows**
 
-  Even if you use compatible algorithms, there can be other reasons why traffic is not flowing. One of most frequent is blocking traffic between peers - that is especially common in public clouds. Make sure that TCP/UDP ports 500 and 4500 and ESP protocol are allowed between the peers. Alternatively, consider enforcing UDP encapsulation on both sides of the tunnel:
+  Even if you use compatible algorithms, there can be other reasons why
+  traffic is not flowing. One of most frequent is blocking traffic between
+  peers - that is especially common in public clouds. Make sure that TCP/UDP
+  ports 500 and 4500 and ESP protocol are allowed between the peers.
+  Alternatively, consider enforcing UDP encapsulation on both sides of the
+  tunnel:
 
 ```{cfgcmd} set vpn ipsec site-to-site peer \<peer-name\> force-udp-encapsulation
 ```
\ No newline at end of file