[strongSwan] ESP transport mode questions

[strongswan user]

Hello all.
I'm experimenting with IPSec and strongswan 5.9.0 on ArchLinux with 
systemd (starting a service by starting charon-systemd and then 
swanctl), Linux kernel 5.9.
For example, my case involves configuring IPSec in ESP transport mode 
between two hosts on the local network. Further I will call them 
"host_a" - its address is 198.51.100.1/24 and "host_b" - its address is 
198.51.100.2/24.
I suppose also to configure strongswan so that only TCP connections 
initiated from host_a to host_b are encrypted:
host_a:any -> host_b:5001;
negotiation of encryption parameters by the IKEv2 protocol, creation of 
an ESP SAs when initiating a TCP connection.
On host_a, the config for swanctl is used (the "secrets" section is not 
shown, as it does not make sense in the example):
connections {
   conn_phase1_to_b {
     remote_addrs = 198.51.100.2
     local { --skip-- }
     remote { --skip-- }
     children {
       phase2_to_b {
       mode = transport
       start_action = trap
       close_action = trap
       remote_ts = 198.51.100.2/32[tcp/5001]
       }
     }
     encap = no
     mobike = no
     version = 2
     pull = no
     unique = keep
   }
}

On host_b, the config is identical, but turned towards host_a:
connections {
   conn_phase1_to_a {
     remote_addrs = 198.51.100.1
     local { --skip-- }
     remote { --skip-- }
     children {
       phase2_to_a {
         mode = transport
         start_action = trap
         close_action = trap
         local_ts = 198.51.100.2/32[tcp/5001]
       }
     }
     mobike = no
     encap = no
     pull = no
     version = 2
     unique = keep
   }
}

This configuration works.

For example, after starting the strongswan service, I see two policies 
set (on host_a, for example), 'ip xfrm policy show':
src 198.51.100.1/32 dst 198.51.100.2/32 proto tcp dport 5001
         dir out priority 366912 ptype main
         tmpl src 0.0.0.0 dst 0.0.0.0
                 proto esp reqid 1 mode transport
src 198.51.100.2/32 dst 198.51.100.1/32 proto tcp sport 5001
         dir in priority 366912 ptype main
         tmpl src 0.0.0.0 dst 0.0.0.0
                 proto esp reqid 1 mode transport

Apparently, these are two traps intended to start negotiating ESP 
parameters using the IKEv2 protocol when trying to pass traffic 
according to the described rules: I will name the first trap "policy_X", 
the second - "policy_Y".

Indeed, if I send a TCP packet host_a:any -> host_b:5001, then the value 
displayed by the 'ip xfrm policy show' changes:
src 198.51.100.1/32 dst 198.51.100.2/32 proto tcp dport 5001
         dir out priority 366911 ptype main
         tmpl src 0.0.0.0 dst 0.0.0.0
                 proto esp spi 0xc469cd4c reqid 1 mode transport
src 198.51.100.2/32 dst 198.51.100.1/32 proto tcp sport 5001
         dir in priority 366911 ptype main
         tmpl src 0.0.0.0 dst 0.0.0.0
                 proto esp reqid 1 mode transport

For outgoing policy_X, the priority has changed and it has become 
associated with ESP SPI 0xc469cd4c. Incoming policy_Y was left unused.
If I look at the output of the 'ip xfrm state show', then two ESP SAs 
are visible, the ID of one of the two SAs is referenced by policy_X, 
0xc469cd4c:
src 198.51.100.1 dst 198.51.100.2
         proto esp spi 0xc469cd4c reqid 1 mode transport
         replay-window 0
         aead rfc4106(gcm(aes)) 
0x9714586eb83fcbf6446bb0e7a2ca408473d03c73 128
         anti-replay context: seq 0x0, oseq 0x9f1b, bitmap 0x00000000
         sel src 198.51.100.1/32 dst 198.51.100.2/32
src 198.51.100.2 dst 198.51.100.1
         proto esp spi 0xc9e9d3aa reqid 1 mode transport
         replay-window 32
         aead rfc4106(gcm(aes)) 
0xbe5edf6a4a3c6310b3d1611437efb0560fd8427c 128
         anti-replay context: seq 0x510c, oseq 0x0, bitmap 0xffffffff
         sel src 198.51.100.2/32 dst 198.51.100.1/32

Questions:
1. Why is the policy_Y set, if after negotiating the ESP parameters and 
configuring the ESP SA, it remains unassociated with any ESP SA?
   I tried to initiate a TCP connection in the opposite direction 
host_b:5001 -> host_a:any, but in this case the observed effect is 
similar to the one described above. I also tried disabling strongswan on 
host_b and re-initiating a TCP connection in the opposite direction 
host_b:5001 -> host_a:any without IPSec, hoping that the policy_Y trap 
would be triggered on host_a, but no: nothing just happens, TCP packets 
are lost.
   Can strongswan be configured so that an unused policy_Y is not installed?
2. Is it possible to configure for a TCP connection not two ESP SAs, 
each acting in its own direction, but one? For example, an exotic case 
where I only need to apply encryption in one direction?

I used a google translator, I apologize for any possible defects in the 
text.

Thanks.