Async SRAM Chip. Write Cycle. Data inputs timings
The doc says that after !WE goes down there is a period of time twhz when signals on I/O pins must be not applied: "4.During this period, I/O pins are in the output state, and input signals must not be applied. "


This is a poorly written data sheet.  While the concern mentioned can exist, the previous note #3 does a poor job of expressing the reality that the problem only exists if the /OE is held low throughout a write, which would not be a common or generally wise practice.

Typically, in a processor bus of this era, the chip select /CS would be driven active low by an address decoder subject to contamination and glitching during the change of the address lines from one value to another.  As a result, a /CS timed write is not generally used.  Nor is it a good idea to have a memory chip driving the data bus surrounding a write cycle, so /OE would not be tied low and the quoted concern would not exist.

Instead, the typical approach is to have the bus master drive the /OE line only if it wished to perform a read operation, and to drive a properly timed strobing of the /WR line at the proper time in a write cycle.

By using /OE to control the output buffers, and using /WR to the time the writes, you should be able to avoid conflict and be able to safely drive the data lines during all periods of time except those surrounding assertion of the active low /OE signal.  Of course, to read from the memory, you will need a way to disable whatever you use to drive the data lines during a write, and to make sure that those drivers are disabled for a safe window around the assertion of /OE.

You are always able to drive the address lines, but their values only matter at the times required before/during/after a write or read cycle.

A simple way to construct a deterministic memory interface may be to create a finite state machine and include the clock low period as a factor in the generation of /OE, its complement to the write data drivers, and /WR.  Keep in mind that a processor itself tends to be a sort of state (or else microprogrammed) machine - with instructions needing multiple clocks (or at least clock phases) to complete.  You really only get to one instruction per clock with heavy pipelining and when operating from distinct internal code and data caches.